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.
