Linux – Why does glibc need kernel headers

The software has to be portable. If you compile your C/C++ sources, then you don't need to know if you running i386/x86_64/arm/mips or what ever. The headers are linked in such way the software compiles.

All other header files exist because they were implemented a lot of different standards, there are ports from BSD and so on. So many of them are historically based. Where each one comes from and why they are there has many different reasons and will surely blow answers.

And an answer for asm-generic: stackoverflow

If it were for any other library, but glibc ... I suppose there can't be quick ways, because the glibc is the place where stuff is "hard coded". The glibc fits to your kernel version and its loader is the instance that actually does the right thing (TM) with LD_LIBRARY_PATH.

Maybe the correct way is to:

LD_LIBRARY_PATH="/opt/myglibc/;..." /opt/myglibc/ld-linux.so.2 the_program`

Not sure if this works, though.

At any rate, I think using an alternative glibc requires a yet to implement framework, because search paths are wired sometimes and the glibc always has to fit your OS/kernel, so there can't be generic binaries, IMO. Debian's multiarch shows that it's not trivial, but still can be done. If one was to have some other means of discerning libraries besides the target architecture.

The website just gave me this other related thread:

• Running a statically linked binary with a different glibc

There, the accepted answer includes a link to a program called rtldi, which seems to solve the glibc issue. It's from 2004 so it may not work right out of the linker anymore, but maybe its worth looking into. Its source is GPLv2.

Jehova, Jehova

A friend of mine once came up with the idea, that the actual use of shared libraries is overrated. And he does have a point: shared libraries are good to not fill up your computer's memory with duplicates, but considering the individual application instance this is only a few MBs.

There is only a few applications where we would resort to actions such as providing them their own glibc. Saving us a lengthy analysis let's call them "immediate applications", that are of use by themselves, in the sense of getting work done. For example web browsers, mail user agents, office suits and music players allow the user to get what they want and there are only a few instances per user. To portrait the other side, system services, window managers, even entire desktop environments are all very important, but merely supporting and often not sufficiently uncommon or critical, so that people would be willing to give them their very own glibc.

The number of "immediate applications" is rather small, absolutely per user and relatively compared to what "basic" OSs and DEs spawn these days. If immediate applications, like Chrome, Firefox were compiled statically, the additional memory requirement for the average system would be a few 100MB. An argument that doesn't carry very far on today's many GB systems so statical linking for immediate applications can be an option.

There are also the concepts of swap space and SSDs which allow for rediculously fast swapin/-out, which also helps handling the increaed memory requirement.

The glibc issue discussed here is not really resolved though static linking, but for applications like web browser a sort of self contained distribution format is conceivable, where the X protocol, some sound daemon and some kernel meethods as the only interface. The advantage would be fewer library version incompatibilities.