Problems building Windows hosted powerpc/arm/mips-elf toolchain using Linux as build machine
Jay
jay.krell@cornell.edu
Tue Sep 16 10:19:00 GMT 2008
> [Oyvind] - do not copy newlib/libgloss into gcc source directory
Really? I can see reasons for and against and suspect I see
a problem (or at least something I don't understand) with
the "merged tree".
Specifically, if I'm building multiple configurations, I should
be able to put newlib in the one source tree, but only use it for certain
configurations, such as embedded and Cygwin.
?
Maybe -disable-newlib is the answer?
e.g.
mkdir /obj/linuxx86-native
cd /obj/linuxx86-native
/src/gcc/configure -disable-newlib -host i686-pc-linux -target i686-pc-linux && make && make install
mkdir /obj/cygwin-cross
cd /obj/cygwin-cross
/src/gcc/configure -with-newlib -host i686-pc-linux -target -i686-pc-cygwin && make && make install
mkdir /obj/cygwin-canada
cd /obj/cygwin-canada
/src/gcc/configure -with-newlib -host i686-pc-cygwin -target -i686-pc-cygwin && make && make install DESTDIR=/somewhere
?
Ideally it is more automatic than that though.
Ideally toplevel configure just knows when newlib makes sense.
Plus, it is ambiguous -- is it newlib for host or target?
I have a sneaking suspicion that there's a lot of ambigous stuff that way -- host vs. target.
At least for CC and such, there is CC (for host), CC_FOR_BUILD, CC_FOR_TARGET.
Similarly -with-sysroot (host), and -with-build-sysroot.
Perhaps everything that matters has already been "multiplied out"?
I'll have to try it at some point..
- Jay
More information about the Gcc-help
mailing list