This is the mail archive of the crossgcc@sourceware.org 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] |
I want to build a mipsel-linux targeted toolchain that runs on mingw.
My first thought was to build it on my i686-pc-linux-gnu system. I have a i386-mingw32msvc targeted toolchain running on my linux system so I thought that I could do:
.../gcc-3.4.3/configure --target=mipsel-linux --build=i686-pc-linux-gnu --host=i386-mingw32msvc ...
However I get:
i386-mingw32msvc-gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I. -I../../gcc-3.4.3/gcc -I../../gcc-3.4.3/gcc/. -I../../gcc-3.4.3/gcc/../include -I../intl \
-DTARGET_MACHINE=\"mipsel-linux\" \
-c ../../gcc-3.4.3/gcc/collect2.c -o collect2.o
.../../gcc-3.4.3/gcc/collect2.c: In function `handler':
.../../gcc-3.4.3/gcc/collect2.c:427: warning: implicit declaration of function `kill'
.../../gcc-3.4.3/gcc/collect2.c: In function `scan_prog_file':
.../../gcc-3.4.3/gcc/collect2.c:2016: warning: implicit declaration of function `pipe'
.../../gcc-3.4.3/gcc/collect2.c:2039: warning: implicit declaration of function `fork'
.../../gcc-3.4.3/gcc/collect2.c:2055: warning: passing arg 2 of `execv' from incompatible pointer type
.../../gcc-3.4.3/gcc/collect2.c:1994: warning: unused variable `quit_handler'
Building collect2 for MinGW HOST doesn't work ! But the MinGW config stuff in GCC disables the collect2 build for MinGW TARGET ! This has been a known bug as far as I can remember and so I have told on the MinGW and on this crossgcc list that the disabling should be taken away from the MinGW target defines and be moved to the MinGW host defines.
But somehow this simple fix has gone over the head or something, or any "temporary" workarounds are not allowed in the FSF sources, things should remain broken until someone fixes them... In this case the problem is that collect2 cannot be built for the MinGW host and the FSF sources are waiting someone to fix this thing...
Would I be better off to try building on the mingw host itself? Or should I just go back and use cygwin?
Building collect2 for the Cygwin host succeeds. It also succeeds for the Linux, FreeBSD, NetBSD,... and for almost any other $host, but not for the MinGW host. Trying to build on MinGW/MSYS doesn't help anything, but most probably totally on the contrary...
So the problem is where you would need the 'collect2.exe' with your crosstools? In which tasks you absolutely require it?
If you don't need something, simply don't desperately try to build it! Just disable the collect2 production and be happy... My guess is that you will never need it anywhere. Just RTFM and then judge the necessity to get this utility, for instance for handling C++ templates with it:
1. Compile your template-using code with ‘-frepo’. The compiler will generate files with the extension ‘.rpo’ listing all of the template instantiations used in the corresponding object files which could be instantiated there; the link wrapper, ‘collect2’, will then update the ‘.rpo’ files to tell the compiler where to place those instantiations and rebuild any affected object files. The link-time overhead is negligible after the first pass, as the compiler will continue to place the instantiations in the same files. ----------------- clip ------------------
The "GCC Internals" manual should tell more about where collect2 is necessary...
Seemingly the MinGW people have not required collect2 for the MinGW target because then the simple solution would have been to produce all MinGW stuff on some other host which allows one to build collect2 for the host, like on Linux... The claim "almost any other host is better for MinGW target development than the native Windoze host", can be easily accepted.
Any advice appreciated.
With your 'mipsel-linux' target it can still be that the MinGW-hosted linker cannot find 'ld.so.1' automagically when linking 'libc.so.6' :
----------------- clip ------------------ F:\usr\local\mipsel-linux-gnu\lib>..\bin\objdump -p libc.so.6
Program Header: PHDR off 0x00000034 vaddr 0x00000034 paddr 0x00000034 align 2**2 filesz 0x000000e0 memsz 0x000000e0 flags r-x <snip> Dynamic Section: NEEDED ld.so.1 SONAME libc.so.6 INIT 0x15490 FINI 0x1410c0 ----------------- clip ------------------
It is 'NEEDED', so the linker should link also against it, if it can find it... But if it cannot, there will be undefined symbols. A simple workaround is to always link against 'ld.so.1' when linking 'libc.so.6':
----------------- clip ------------------ F:\usr\local\mipsel-linux-gnu\lib>type libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ GROUP ( libc.so.6 ld.so.1 libc_nonshared.a ) ----------------- clip ------------------
------ 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] |