This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Cross Compiler Unix - Windows
On 26 Aug 2005, Kai Ruottu complained:
> Not even mentioning Linux and its GCC idea: "There can
> be only one!", seemingly borrowed from the "Highlander" -- that all the
> GCCs on a host system should use a common $prefix has seemingly been
> totally unknown by the Linux people and they really expected the native
> GCC to be the only GCC ever on that host! Or that if one needs more
> GCCs, they can only be other versions for the native GCC...
This is nonsense. I have a dozen cross-compilers on this box, all
installed into /usr. They do not collide as long as you configure with
--enable-version-specific-runtime-libs and
--program-{prefix,suffix,transform-name} and make slight adjustments
after installation (ditch libiberty.a and some locale and manpage stuff
that doesn't get its name suitably adjusted).
There is nothing whatsoever special about the system compiler on Linux.
It's just a GCC configured with particular switches, that is all.
> The '--with-sysroot' tries to keep the 'proprietary' layouts even on
> the cross-hosts, where people could always use the "standard install
> layout for GCC", every GCC installed using just the same rules. So the
> situation where all crosscompilers use their own proprietary layouts
> has somehow been seen being better that trying to standardize the GCC
> installation layout.
Er, GCC will always look in ${tooldir}/lib for libraries, ${tooldir)/bin
for binaries, and so on. (Your comments below indicate that you know this:
so what are you talking about here?)
> The current cross-GCC install layout has its problems : there is only
> one $target dependent place for the libraries when a typical native GCC
> has at least two, '/lib' and '/usr/lib'.
If you are installing libgcc_s.so* into /lib, you'd better damned well
know what you're doing, as you'll be overwriting the distribution's
copy. Doing it automatically strikes me as a seriously bad idea: anyone
installing an old GCC in parallel with a new one would stand at risk of
wrecking every program on their system dynamically linked against
libgcc_s. (Those of us who don't use distributions generally have
installation-time scripts that can do the necessary by-hand mv.)
There were huge flamewars^W^Wintense debates about this when libgcc
was made into a shared library: look at the list archives.
> Meanwhile a cross-GCC has two
> places for the headers: the '$tooldir/include' for the standard (posix)
> headers and the '$tooldir/sys-include' for the system-specific
> (non-posix etc.) headers.
Personally I've never quite seen the point of sys-lib and sys-include.
I just dump all the target libraries and headers into the target-
specific lib and include directories. :)
> However anyone who has built more than 10 GCCs for more than 10 targets
> and then installed them on the same development platform, has somehow
> got used to the current (but limiting) layout, and has solved the
> problems somehow. For instance what to do with the Solaris2 '/usr/lib',
> '/usr/ccs/lib', '/usr/ucblib', '/usr/ccs/ucblib' and so on library
> places someone recently had some problems with.
I created ${tooldir}/ccs/lib et al and just had a site-config script
construct suitable -L arguments to GCC. (If you're doing much
cross-compilation you'll end up with a site-config script full of all
sorts of stuff anyway. This is nothing by comparison.)
> Ok, as long as there are those stupid installs to '/usr' on the native
> front, as long people must think how on earth the natively installed
> C libraries can be copied to the cross host.
Er, NFS? cp? tar? All of them work.
> Linux is a good example
> about this stupidity in the very beginning. Instead of thinking how
> one could produce apps for Linux easily on ANY host, it was thought
> how one could produce apps for Linux ONLY on the Linux host and so
> trying to make cross-compiling to Linux as hard as possible.
It's not hard. Just lump everything in /lib into the same place as
everything in /usr/lib on the compilation host, and everything will
work fine.
> Not using '--with-sysroot=' at all, but simply putting the '/lib'
> and '/usr' stuff below a '$sysroot' and then symlinking the
> '$sysroot/usr/include' and '$sysroot/usr/lib' to be seen as 'include'
> and 'lib' on the $gcc_tooldir, adding a couple more symlinks to the
> 'lib' and editing the absolute paths away from the 'libc.so', enables
> one to get a Linux-targeted GCC to work.
Indeed it does. (The libc.so absolute paths are... silly, but that's
not something you can blame on GCC. Best of luck convincing Ulrich
to change it.)
> With 64-bit bi-arch targets
> one of course uses the default 'lib64' as the place here the
> $gcc_tooldir/lib' leads to... No need for '--with-sysroot=' with the
> 64-bit bi-arch targets either.
Yeah, but they're not really cross-compilers in that sense: they're
native compilers with extra magic (hardwired into the appropriate
backend code, no less; somewhat icky, I feel, but I can't think of a
better way to do it myself: unlike binutils, GCC just doesn't have the
generic infrastructure for multiple-simultaneous-target support, and
until *everything* is hookized is unlikely to. I imagine hookizing
everything would have another negative impact on compilation speed,
which is hardly a good thing.)
I'm not sure what you're complaining about here: your English is just
fractured enough to impair my comprehension. Is it --with-sysroot you
dislike (in which case, ditto: what's it meant for?), or is it
installing multiple parallel compilers in /usr (which works just fine)
or what?
--
`... published last year in a limited edition... In one of the
great tragedies of publishing, it was not a limited enough edition
and so I have read it.' --- James Nicoll