Mystery of glibc-2.2.*

Ervin Németh airwin at
Fri Mar 2 04:19:54 PST 2001

Hi list,

I want to share my experince of glibc with you.

I am using a self-built system though I had no idea of
The first problems started as I was upgrading my kernel from 2.2 to 2.3:
large file support has stopped working.  To be precise the *stat functions
returned wrong values entirely ruining "make" for example.

Now I have a 2.4-kernel, but since glibc-2.1.3 I am unable to upgrade my libc
because of the compilation error reported by others too: crashes
at its first use in the directory sunrpc while running rpcgen with the file
rpcsvc/bootparam_prot.x.  The error message was "Value too large for defined
data type" at my first try with CFLAGS="-pipe -march=i686 -malign-double
-fstrict-aliasing" and a "simple" segfault when I left out double aligning.

This week I was trying to build an LSF system starting from debian potato.  I
was surprised that glibc-2.2.2 has compiled without error.  I started to
experiment with this new build discovering that dynamic executables compiled
against the debian libc runtime-linked with this new libc and running under
2.4 kernel resuled every *stat call returning with an ""Value too large for
defined data type" error.  I think it could be successful because debian comes
with 2.2 kernel headers.

One last thing.  Using 2.4 kernel and 2.1.3 glibc together with every
application forced with disabled large file support shows some problems too: a 
strace with "mount" has showed me that lstat is redircted to lstat64 which
then fails.  So mount cannot examine mtab.  Fortunately making mtab a symlink
to /proc/mounts is a good workaround.

Summa summarum glibc with 2.4 linux is a disaster.

Anybody confirming this?  Any solution?

Plenus venter non studet libenter.

Unsubscribe: send email to lfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the lfs-dev mailing list