Crosstool chain on MinGW

Kai Ruottu karuottu@mbnet.fi
Wed Nov 12 12:09:00 GMT 2003


"Manoj Verma, Noida" <manojv@noida.hcltech.com> wrote:

> As I have been trying to build crosstool chain for "target=arm-linux" on
> "host=i686-pc-mingw32".
>
> 1) Binutils-2.11.2 -> Installed successfully. Option used,
> ../binutils-2.11.2/configure --target=arm-linux
> --prefix=/c/MinGW/msys/home/cinstall_armlinux

> 3) While installing GCC, I get the message-> " configure: error:
> installation or configuration problem: C compiler cannot create
> executables."

 In the GCC-case the C compiler ('cc1') doesn't create executables, neither
do the 'gcc', 'cpp' and 'cc1' together. So the error message is quite wacky...
This should tell "The link phase in compile & link cannot create executables."
or something more sane.

> When I compile a sample program as:
> $ arm-linux-gcc sample.c,
> I get following errors:
> **************************
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccGSaaaa.s: Assembler messages:
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccGSaaaa.s:1: Error: invalid character
> '@' in mnemonic
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccGSaaaa.s:11: Warning: .type pseudo-op
> used outside of .def/.endef ignored.
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccGSaaaa.s:11: Warning: rest of line
> ignored; first ignored character is `m'

 Maybe your binutils-2.11.2 is too old or more probably here the native 'as' was found
first...  Please try a 'arm-linux-gcc -v -o sample.x sample.c' and see which 'as' was
used!

> I get following errors:
> **************************************
> ./cinstall_armlinux/arm-linux/lib\libc.so.6: undefined reference to
> `_dl_lazy@GLIBC_2.1.1'
> ./cinstall_armlinux/arm-linux/lib\libc.so.6: undefined reference to
> `_dl_dst_substitute@GLIBC_2.1.1'
> ./cinstall_armlinux/arm-linux/lib\libc.so.6: undefined reference to
> `_dl_fpu_control@GLIBC_2.1'
> ./cinstall_armlinux/arm-linux/lib\libc.so.6: undefined reference to
> `_dl_global_scope_alloc@GLIBC_2.1'

 I think it was you to whom this "Cannot find the NEEDED shared
libraries automagically" was described already... Yes, I found a reply
from October and have sent it once again...

 But a 2nd try comes here:

 Please try the following command with your
 './cinstall_armlinux/arm-linux/lib\libc.so.6' :

    arm-linux-objdump -p libc.so.6

and see what the 'NEEDED' tells... There should be told that the 'ld-linux.so.2'
is needed by the 'libc.so.6'.  The linker should see this and then link against
it automagically, but this doesn't work in the MinGW-hosted linkers. It works
in the Cygwin-hosted linkers though...

 The workaround is to put your 'libc.so' script to have something like:

    GROUP ( libc.so.6 ld-linux.so.2 libc_nonshared.a )

ie. linking always against these three instead of the original two...

> p.s: when I do the same step on Cygwin to build the tool chain, everything
> build perfectly fine.

 Another workaround is to use a Cygwin-hosted 'ld' with the otherwise MinGW-
hosted stuff...

 But the best approach could be to try to find the bug in the GNU linker, I
remember sending clues about where the bug could be... Definitely someone
from the MinGW world could have met the same problems like comparing
inode and filesystem (disk) numbers for two files and other Unix-like things in
the used sources originated from Unix.  Anyhow one of the suspect places has
been taken here again: 

> Ok, one suspected place is in 'ld/emultempl/elf32.em' :
> 
> ----------------- clip -------------------------------------
> /* See if an input file matches a DT_NEEDED entry by running stat on
>    the file.  */
> 
> static void
> gld${EMULATION_NAME}_stat_needed (lang_input_statement_type *s)
> {
>   struct stat st;
>   const char *suffix;
>   const char *soname;
> 
>   if (global_found)
>     return;
>   if (s->the_bfd == NULL)
>     return;
> 
>   if (bfd_stat (s->the_bfd, &st) != 0)
>     {
>       einfo ("%P:%B: bfd_stat failed: %E\n", s->the_bfd);
>       return;
>     }
> 
>   if (st.st_dev == global_stat.st_dev     <---- !!!
>       && st.st_ino == global_stat.st_ino) <---- !!!
>     {
>       global_found = TRUE;
>       return;
>     }
> ----------------- clip -------------------------------------
> 
> Both the disk # and inode # must match here...

 This 'NEEDED' problem should be a known bug, but no tries to fix it has not been seen.
At least I have reported this on the MinGW maillist...  My MinGW-hosted and Linux-
targeted toolchains were built just for a fun without any payment ever and never needed
for anything, so there has not been any reason to do anything else than notice and
report the found problems. If you will be paid for your work with the MinGW-host, you
could have some reasons to fix these bugs...

Cheers, Kai




------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com



More information about the crossgcc mailing list