Re: Cross Compiler Unix - Windows

[Kai Ruottu <karuottu@mbnet.fi>]

Mike Stump wrote:

> configure --with-headers=/cygwin/usr/include --with-libs=/cygwin/usr/ 
> lib target=i386-pc-cygwin && make && make install
> 
> would be an example of how I used to build one up, see the gcc  
> documentation for details.  --with-sysroot or some such might be  
> another way to to do it now-a-days.

  That the 'native' Cygwin GCC mimics some unexisting proprietary native
'cc' in its headers and libraries directories instead of just being only
another "C/C++/Java/Fortran/..." compiler set on Windoze, like those
GCCs for 'h8300-*', 'sh-*, 'arm-*' etc. GCCs without any GCCs on their
'native' area, has always been very weird... The same thing happens with
the 'official' MinGW GCC, it too tries to mimic some still unknown
native 'cc' !  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...

  Platforms like Solarises, AIXes, HP-UXes, Irixes, SVR[3-5],... really
have their proprietary native 'cc's which GCC has some sane reasons to
mimic and so try to access their installed headers and libraries from
their original places. But the native-GCC will be installed into some
'local' or 'options' place, '/usr/local', '/opt/gcc' or something, where
one can add as many other GCCs as one wishes. Not to the '/usr' as has
been the rule on those "no native 'cc' seen ever here" platforms. Is
there any sane reasons for this on systems which never have had that
non-GNU native 'cc' ?

  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.

  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'. 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. And maybe the last 10 years or so the GCC
developers have mixed these apples and oranges, standard and system
things, so the cross-GCC build has been a continuous mess, target
headers being searched from the 'sys-include' when the de-facto place
is the 'include' (For instance the newlib install puts the target 
headers to the 'include' and they are there when one wants to try to
build a newer GCC.) And such... If most of the native GCCs have only
the '/usr/include', the STANDARD_INCLUDE_DIR, and there is no place for
the SYSTEM_INCLUDE_DIR (please search the GCC manuals for this), is it
so hard to leave the 'sys-include' unnoticed?

  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. And before the
'--with-sysroot' appeared at all...

  Before trying to move the proprietary layouts into the peaceful?
land of cross, it could have been better to ask the crosscompiler
builders how they have solved these "copy the target headers and
libs from the native system and put them to work with the cross-GCCs
too" problems. Maybe then there had no reason for the '--with-sysroot'.
Does it even work as one would expect it to work, solving those '/lib'
and '/usr/lib' in the 'libc.so' script problems and so on?

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

  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. 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. "It is vain to produce anything for the
idiots to follow, because idiots are so clever and always invent a
better way to do just the same thing!" (Was the '--with-sysroot' made
for people who are not as clever as we cross-GCC people who were
considered being complete idiots? :-)

  What becomes to Cygwin and MinGW, the same attitude as followed with
Linux, that "producing any apps for Windoze should happen only on
Windoze, or that when one does it on some other host, it still should
happen just like on Windoze!", is totally weird to me. My thought would
be: "Producing apps for Windoze on Windoze should happen just like it
happens on any other host, and at the same time quite in the same way
as it happens with any other GCC which is hosted on Windoze!".