This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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 > > > ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |