baffled by glibc

Michal Jaegermann (
Sun, 18 Jan 1998 11:13:06 -0700 (MST)

Can somebody explain why this header separation between glibc and kernel,
touted as "the best thing from a sliced bread", is really such a good
thing? The only answer I have seen so far is that this will allow
independent changes of various structures and definitions in kernel

That is the point! A lot of system utilities **has** to know these sizes.
So far I have seen on this list a breakage in NFS, ncpfs, smbfs caused
by a mismatch in definitions between these two sets of headers and tons
of time wasted in heroic efforts to discover what is causing strange bugs
(with some voices pipin in "It works for me" but they have still previous
libraries/headers). I fully expect that if one would recompile ext2fs
with glibc then it will promptly break too. Probably we do not hear a
big outcry because most of people has tools still compiled with previous
headers and libraries. Add to this a nonchalant attitude of some folks,
who never seen 16-bit or 64-bit machine, towards freely swapping things
like 'int' and 'unsigned long' and we have a recipe for a disaster.
It smells to me that a lot of toubles which Red Hat had with a recent
release 5.0 for Alpha was caused exactly by that.

Even when things start to settle a bit it looks like in a future hitting
'make' with a new releas of Samba, say, will be an extremely risky
proposition. "This source is using gid_t. But wait, in this place this
has to be 'kernel gid_t' and few lines further this is 'glibc gid_t';
it is used in a library function call! Run away! 'kernel gid_t' was
just changed to a type 'foo' in the lastest kernel sources release!".

So why all these troubles? What this is exactly expect to buy us
for all current and future headaches?