Messages in this thread | | | From | Michal Jaegermann <> | Subject | baffled by glibc | Date | 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 headers.
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?
Michal
| |