Home / server / Questions / 441743
Accepted
Zac B
Asked: 2012-10-25 03:58:43 +0800 CST

Per-application library paths on CentOS

  • 772

Context:

After a recent version upgrade of a bunch of our server software, I've found myself in a dilemma:

I have two sets of applications (Zend server and assorted utils, and a bunch of PostgreSQL management utilities) that both heavily use a certain library file (libpq.so). Zend ships with its own libpq, which is the only version (that I've found) that will work with all of the Zend stuff. Postgres also ships with its own version of the library. The two are mutually exclusive: if Postgres's version of the library comes first in the LD_LIBRARY_PATH of whatever user is doing something, all of the Postgres utils will work, but none of the Zend ones will. If Zend's comes first, the Zend stuff will work, but the Postgres stuff won't.

The libraries both have the same names. The PostgreSQL compatibility libs package doesn't work.

In our environment, both sets of applications are used under a lot of different, unpredictable user accounts on a lot of different CentOS machines, so using the "right way" and setting LD_LIBRARY_PATH per-user, and telling people to "only use X applications under Y account" will not work.

Question:

Is there a per application way to say "for these binaries/apps executed in X folder, link against a library at path Y, but for these other binaries, link against library Z"? Basically, a per-application library path, without having to set LD_LIBRARY_PATH or DYLD_* every time I access one of the applications.

I'd prefer to avoid having to recompile libraries, since that would sign me up for a significant additional amount of hassle and testing every time a new version of either set of software comes out. I already have libraries that work, they just won't work for both sets of apps.

centos

2 Answers

  1. Best Answer

    Embedded search paths

    There is one option that will give you what you want:

    When building an application you can set the LD_RUN_PATH environment variable and this will get compiled into the application. In theory the chrpath command will let you modify the embedded path in an application without needing to recompile it, but I've never tested this myself.

    chrpath is available in Fedora, but I can't find an authoritative source for the, err, source.

    You mention DYLD_* variables, which suggests you're working under OS X, in which case the above may not apply to you. This is certainly true for Linux but the OS X runtime linker may not operate the same way (and chrpath may be a Linux-only tool).

    Managing your environment

    A common way of managing per-application LD_LIBRARY_PATH settings is a wrapper script, as ewwhite suggested, or by using something like the Environment Modules project. This lets you package up environment variable settings (and more) into distinct units so that you do something like:

    module load myapplication

    And have your PATH, LD_LIBRARY_PATH, MANPATH and everything else set up appropriately for access to myapplication. And when you're done, you can:

    module unload myapplication

    To undo the environment changes.

    • 4

  2. The normal approach to this in my background has been to use a wrapper script to execute the applications. In that wrapper script, the LD_LIBRARY_PATH would be set for the specific application. The variable could optionally be unset after execution is done.

    • 0