Re: Is a target glibc really needed to build full crossgcc?

[Kai Ruottu <karuottu at mbnet dot fi>]

Ralf Corsepius wrote:
> On Wed, 2005-09-14 at 14:10 +0200, Henrik Bechmann wrote:
>
> > Hi,
> >
> > When you build a cross compiler toolchain, you have to build glibc berfore 
> > you can build the full gcc.
>
> This is not quite correct. 
>
> You don't have to _build_ it, you have to _have_ it!
>
> I.e. instead of building glibc as part of building a cross toolchain, it
> is way easier to extract the target library binaries + headers from a
> target binary package and to install them to appropriate locations, in
> advance to building GCC (cf. --sys-root, --sys-* configure script
> options in GCC).

 And the C library can be something else than the 'glibc' used with
the Linux targets. Sun Solaris'es have their own proprietary C libs,
just like HP-UX, AIX etc. Cygwin has its newlib-based custom C library,
MinGW has import libraries for the CRTDLL.DLL and MSVCRT.DLL runtime
C libraries from MS, DOS/DJGPP2 has its own custom C library, FreeBSD,
OpenBSD and NetBSD have also their own custom BSD-libraries...

> Of cause this only works if binaries of the target libraries are
> available somewhere. This applies to many Linux targets, where you often
> can use the libraries being shipped with distributions.

 The prebuilt C libraries are always available for the free systems,
but also some proprietary systems also have their prebuilt C libraries
for free download. For instance SGI has its Irix5 and 6 C libraries
downloadable. Some systems which claim to be 'free', like Apple's Mac
OS X and the "Enterprise Linuces", then don't put their binaries for
free download. The sources then can be freely available, for instance
the "Darwin" C library sources and those "ES" model sources...

 My opinion to this is, and has always been, that one not only "can",
but "should" use the original prebuilt and already tested C libraries.
Replacing them with something else in the crosstools is not at all
recommended. If there is no serious aspect, no paid work to do, it
not mattering if the produced apps don't work, etc. which is usual in
those "just for a fun" projects, then one can do anything. Trying to
run apps made for Red Hat on SuSE can be interesting, or trying to
run apps made with a generic self-built toolchain on them both could
also be...

> > But is the cross glibc libraries actually needed to 
> > build the full crossgcc,
>
> Yes, GCC's configure scripts can try to link against the library when
> building other libraries as part of building GCC.

 The produced 'libgcc_s.so's and 'libstdc++.so's are examples for these,
producing shared libraries happens quite in the same way as producing
executables.

 With all the system targets the prebuilt and preinstalled target C
library will be investigated by compiling and linking short programs,
'stubs', which test the availability of functions, their working and
such. So the preinstalled target C library is obligatory...

 With the embedded targets using 'newlib' as their C library, it is
fully possible to build a complete GCC immediately when only having
the generic newlib headers preinstalled. The '--with-newlib' option
enables this, it removes all the C library tests and cause ready made
answers to be given to the configure scripts. At least in theory, as
usually there are long lasting features/bugs in the GCC sources. For
instance the 'libiberty' configure claims that functions 'asprintf()',
'strdup()' and 'vasprintf()' aren't implemented in newlib. But they
are there since the release '1.10' or so.

 When the Linux targets are only a small minority among all the
possible targets for GCC, one can say that in most crossgcc cases
the GNU C library will not be used at all and then building glibc
has nothing to do with most cross-GCC builds !  During the history
of GCC, the C library has always been an alien which should be
checked and suspected, its headers needing fixing (with the provided
'fixincludes/fixinc') and its libraries being limited and therefore
needing the 'libiberty' to add all the missing functions...

 Generally a normal cross-GCC will be built in one 'stage', not in
three, and no C library build happens during the GCC build.  One can
update (or build from scratch) the C library after the GCC is ready, but
that is totally another project, not a cross-GCC build... Where those
wacky current 'gurus' have invented their ideas about that three-stage
build process, remains unknown... Or maybe working around the GCC bugs
that way has becomen "the habit of the land of cross", not trying to
report those bugs in order to get them finally fixed.

 If enough people would believe that a cross-GCC really is aimed to
be built in one stage after building the binutils and preinstalling
the existing target C libraries, and would report any problems in
this normal build type, the world would be much simpler and easier.
But "people are like chaff in the wind, as soon as enough people are
believing in something, others will follow easily!", Georg Henrik von
Wright... So the three-phase nonsense will stay for a while because
so many are now believing it being just the right way :(


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