Re: What is the best way to create a cross toolchain running on mingw?

[Kai Ruottu <karuottu at mbnet dot fi>]

David Daney wrote:
> 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:

----------------- clip ------------------
In the mean time, you have the following options for dealing with 
template instantiations:

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.

 Just edit your $build/gcc/Makefile and change the :

    USE_COLLECT2=collect2

to be an empty :

    USE_COLLECT2=

and then it will not be built!

 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

libc.so.6:     file format elf32-tradlittlemips

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

 Workarounds required until things are finally fixed....

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