problems with libc5 base system and GCC
mbenkmann at gmx.de
Fri Nov 17 12:33:08 PST 2000
has anybody successfully completed a 2.4.x LFS system using a libc5 base?
I'm beginning with chroot now and I've encountered the following problems
so far, using my SuSE 5.3 as base system:
1) I had to update binutils and gcc and install gettext, maybe some other
packages, too. Well, that's not really a problem.
2) Certain packages (e.g. sed) have regular expression functions that are
in conflict with those in libc.a. This manifests in warnings during
"make". I don't think it is fatal but just to be on the save side I used
"ar d libc.a rx.o" before compiling those packages. For one package I also
had to do that for getopt.o.
3) Even though neither "make" nor "make check" reported any failures, the
"chown" command didn't work on directories. It gave me a "function not
implemented" error when chowning in chroot. I just replaced chown with a
statically linked chown from a libc6 system. This is probably not a
problem for a normal LFS installation as chowns on directories probably
don't happen before chown is recompiled in chroot.
4) When compiling the static gcc, its "specs" file was set up to use
ld-linux.so.1 as dynamic linker. This means that the first ./configure
already failed in chroot (meaning I can't even recompile gcc in chroot).
You can't even execute a simple hello world program compiled in chroot. I
wonder why this isn't mentioned in the LFS book. I can't believe this is a
SuSE specific problem. It should affect all libc5 systems which means that
no one can build LFS with libc5 as base just following the book. Anyway,
the necessary fixes to the specs file are in the glibc FAQ. However, it's
not obvious that the respective point applies to this problem because it
looks like instructions only necessary for old GCCs. The LFS book should
contain a note regarding this in the section about compiling the static
5) glibc fails "make check" with a segfault in one of the checks. I
haven't figured out why and I'll just hope the problem doesn't surface
before I can recompile glibc in chroot. BTW, if I haven't overlooked it, a
glibc recompile is not on the list of stuff done in chroot. That should be
changed. As my abovementioned segfault shows, glibc can be partially
broken even if make didn't fail. Additionally, if your base system didn't
have gettext installed, glibc will build without internationalization
support. This is mentioned by configure but if someone does not enter
.."/configure" separately but pastes the ..&&..&&.. from the book this
message will just scroll past him. Besides, it should also be a matter of
LFS philosophy that no "outside" components should remain.
If everything seems to be going well, you have obviously overlooked something.
Unsubscribe: send email to lfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the lfs-dev