Kai Ruottu wrote:
As this example shows, the GCC build tries to produce the 'libgcc_s.so.1' by linking against the already available target C library, and tries to link simple dummy stubs when configuring the extra libiberty and libstdc++-v3 components. Unless one disables producing the shared libraries.
This can be understood wrong... The last clause was for producing the 'libgcc_s.so.1' and such, 'libgcc_s-nof.so.1' maybe for the 'soft-float' case in Linux/PPC. Trying to produce libiberty and libstdc++ will always try to link small dummy stub programs as one part of their configuration. And so the target C library being working is obligatory... About installing the target C library I can only say that producing glibc from sources and then installing it with 'make install', isn't any easier than just unpacking some prebuilt glibc RPMS. Both require just the same fixes after the base installations. But glibcs taken from SuSE can be harder than those from Red Hat or Fedora, the SuSE ones have always had symlinks to the absolute '/lib' when the self-made and self-installed ones plus at least the Red Hat ones, have relative symlinks to the '../../lib' from their '/usr/lib'. Not a serious nuisance after the first install, during it one usually prepares a script with commands : ln -f -s ../../lib/<the_libname_in_lib> <the_libname_here> to be run in the '/usr/lib' install place, '$sysroot/usr/lib' to fix those bad symlinks...
