14

Time and time again I see questions such as these:

And these are the types of solutions we're typically pushing:

Is this really the best we can do? Aren't there binary builds of GLIBC that we can simply unzip into a directory such as /opt/myglibc, and set the $LD_LIBRARY_PATH or whatever and run whatever application we want, without issues?

An application, such as the newer builds of Chrome (28+) that appear to require GLIBC 2.14?

NOTE: This thread titled: Google Chrome 29 Released – Install on RHEL/CentOS 6 and Fedora 19/15 on tecmint.com is what ultimately got me thinking about this.

References

Improve this question

1 Answer 1

Reset to default
2

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:

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.

Improve this answer
13
  • 2
    "we're talking about a few 100MB here" Uh, no. Although the bulk of the libraries themselves may not be that much (but probably a order of magnitude or two more than 100 MB -- try du -h /lib), keep in mind that if those were compiled in statically, that amount of RAM would be required for each and every application compiled with them. So if, eg. you have two apps using the same library stack, now you'll need twice as much memory. Three apps? Three times as much. Not to mention it would largely negate the benefits of caching...
    – goldilocks
    Commented Nov 14, 2013 at 20:26
  • 2
    ...since, of course, you couldn't just cache glibc -- you'd have to cache copies of every applications that's run (== ridiculous). In short, modern operating systems would plain and simple be totally impossible on modern hardware if it were not for modern techniques such as shared objects. You wouldn't need just a bit more memory -- you'd need 10 or 100 times as much memory.
    – goldilocks
    Commented Nov 14, 2013 at 20:28
  • My Debian has 235MB in /lib, of which 202MB are kernel modules. Yes, /usr/lib is 4GB, but that allows precicely no conclusion on how much the individual program requires. The caches of processors are only a few MB. With the memory consumption of something like a recent web browser, the impact of statically linked binaries on caching is also not that big and diminishing with the amount concurrently running programs; also for the reason of relatively small caches. My estimations seem more accurate than yours. Uh, yes.
    – Bananguin
    Commented Nov 14, 2013 at 21:48
  • Not to mention the other huge problem with static linking—updates are a PITA. If there is a security issue in glibc, no big deal: upgrade glibc, restart your programs. OTOH, were your programs statically linked, you'd have to download a new version of every program. And your distro would have had to recompile (or at least re-link, if they kept all the .o files, unlikely due to huge size) the entire distro.
    – derobert
    Commented Nov 14, 2013 at 22:44
  • 1
    @derobert : Seems fair. Clearly my claims were hyperbolic -- here with 1.8 GB committed that spat out 521 MB. So that would be a 30% increase. Of course, that is still not a selling point for a strategy that has no advantages (but "only requires 30% more RAM").
    – goldilocks
    Commented Nov 15, 2013 at 14:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .