problems with libc5 base system and GCC

Matthias Benkmann mbenkmann at gmx.de
Fri Nov 17 12:33:08 PST 2000


Hallo,
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 
gcc.

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. 

MSB

----
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 mailing list