Update ldconfig cache without root permission

Question

$ uname -a
Linux xhost10.bcgsc.ca 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

$ /sbin/ldconfig --version
ldconfig (GNU libc) 2.5

I am installing several binaries and libraries locally, since I do not have root access.

Some of the programs need to dynamically link to a shared library in a non-standard location at runtime.

When executed, the program returns:

$ path/to/cc1
path/to/cc1: error while loading shared libraries: libmpc.so.3: cannot open shared object file: No such file or directory

I've added paths to the libraries $LD_LIBRARY_PATH, but I cannot update the ldconfig cache without root access...

Is there a user-specific /etc/ld.so.cache?

Or more generally, is it possible on to 'mask' a system configuration file with a user configuration file?

Airworthy

I can get ld.so to find the shared libraries by exporting LD_LIBRARY_PATH in ~/.bashrc and re-login. Running binaries that dynamically load libraries in LD_LIBRARY_PATH seem to take much longer to initialize (shared network filesystem), but at least they run... – Airworthy

Answer 1

The ldconfig cache only applies to path specified in /etc/ld.so.conf or /etc/ld.so.conf.d. As these are not writable for non root users you can't use them to improve start speed for executables installed without root permissions without the help of root (but even then it would be a bad idea to add a file writable to a user to these system wide library search pathes).

So for these cases you need to use either the LD_LIBRARY_PATH environment variable or rpath/runpath in the executable or library that depends on libraries in the non default path. I'm not aware of any speed differences between LD_LIBRARY_PATH and rpath/runpath but rpath/runpath have the advantage that they affect only specific executables and thus are less likely to cause problems for other programs.

In linux/unix there is not general way to mask a system configuration file and use a user supplied file instead. In fact that is something that the unix security model actively has to prevent to avoid various kinds of privilege escalation. That's the reasons even many environment variables get disabled for suid executables for example. Many programs have their one ways to specify overriding user configuration, some more complicated ones also have ways for the system administrator to set mandatory settings that are not overridable.

Pikeman