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] |
"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] |