Glibc hell

[Spacen Jasset]

Steven Schveighoffer wrote:
> "dsimcha" wrote
>> Apparently, DMD for Linux requires a non-ancient version of Glibc to work, 
>> and
>> worse yet, all the stuff compiled by it requires a similarly non-ancient
>> version.  The problem is that I'm trying to run some jobs on a cluster 
>> that
>> has an ancient version of Linux that my sysadmin doesn't want to upgrade.
>> Given that i don't have any root/admin privileges, and will never get 
>> them,
>> does anyone know of a workaround to make DMD, or at least stuff compiled 
>> by
>> it, work with ancient versions of glibc?
>>
>> P.S.  Nothing illegal/unethical, such as cracking the root acct. please.
> 
> You may have to statically link (which, of course, is not officially 
> supported by glibc, for very stupid reasons).  I'm not sure how much of the 
> new glibc is required by dmd, part of glibc is in the dynamic linker, which 
> I think is hard to use a local copy of.
> 
> However, the linker does support a way to override which libraries to use.
> 
> I'd suggest the following.  I assume you have a local account with some 
> space.
> 
> mkdir ~/libs
> cp my_glibc.so ~/libs
> cp my_supporting_lib.so ~/libs
> ...
> # bash syntax, not sure of csh syntax
> export LD_LIBRARY_PATH=~/libs
> 
> What this does is make the dynamic linker use ~/libs to look for dynamic 
> libs to link in before the default ones.  You can check which libraries the 
> dynamic linker is using to resolve dependencies by using 'ldd executable'.
> 
> Hope this helps
> 
> -Steve 
> 
> 

I am not sure that the reasons are "stupid". It is similar, for example 
to kernel32.dll on windows, which you cannot link to statically *at all* 
libc is a comparable interface in that it calls into the kernel.

Linking to an older libc should ensure a good level of compatibility 
going forward, but I am not an expert on this. We do this for some of 
our software at the moment, which works without trouble.