Glibc hell

[Steven Schveighoffer]

"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