RE: Crosstool chain on MinGW

["Manoj Verma, Noida" <manojv at noida dot hcltech dot com>]

Hi Kai,
Thanks ..

By making the entry of ld-linux.so.2 in 'libc.so' script as,
     GROUP ( libc.so.6 ld-linux.so.2 libc_nonshared.a )

The linking errors are gone.

But, when I try to execute the generated image on the target it says:
bash: ./myExe no such file and directory.

On doing "readelf" over this image it reveals the following statement in the
"Program header" section:
"[Requesting program interpreter: /usr/lib/ld.so.1]"

On my target board there is no such file in the required path.
So I copied the ld-2.2.3.so to  /usr/lib/directory and created ld.so.1 as a
softlink to the ld-2.2.3.so.

Now when I execute my program, it says segmentation fault.

Does that mean, my tool chain is not built properly? If not what could be
the reason?

> Kai wrote...
>  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!

Yes, it picks up the Native as. I have tried giving the --with-as=$TARGET-as
gcc configure option. The problem persists. 
How do I make $TARGET-gcc to pick the $TARGET-as?

Thanks 

> -----Original Message-----
> From: Kai Ruottu [mailto:karuottu@mbnet.fi]
> Sent: Wednesday, November 12, 2003 5:37 PM
> To: crossgcc@sources.redhat.com; libc-alpha@sources.redhat.com
> Cc: Manoj Verma, Noida
> Subject: Re: Crosstool chain on MinGW
> 
> 
> "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
> 
> 
>