What's the Accepted Method for Deploying a Linux Application That Relies on Shared Libraries

What's the accepted method for deploying a linux application that relies on shared libraries?

Every "serious" commercial application I have ever seen uses LD_LIBRARY_PATH. They invariably include a shell script that looks something like this:

#!/bin/sh

here="${0%/*}"  # or you can use `dirname "$0"`

LD_LIBRARY_PATH="$here"/lib:"$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH
exec "$0".bin "$@"

They name this script something like .wrapper and create a directory tree that looks like this:

.wrapper
lib/  (directory full of .so files)
app1 -> .wrapper (symlink)
app1.bin (executable)
app2 -> .wrapper (symlink)
app2.bin (executable)

Now you can copy this whole tree to wherever you want, and you can run "/path/to/tree/app1" or "/path/to/tree/app2 --with --some --arguments" and it will work. So will putting /path/to/tree in your PATH.

Incidentally, this is also how Firefox and Chrome do it, more or less.

Whoever told you not to use LD_LIBRARY_PATH is full of it, IMHO.

Which system libraries you want to put in lib depends on which Linux versions you want to officially support.

Do not even think about static linking. The glibc developers do not like it, they do not care about supporting it, and they somehow manage to break it a little harder with every release.

Good luck.

Deploying self-contained native OCaml application

OCaml with its all static approach should already work out of box. All OCaml executables are statically linked with OCaml libraries. What concerning non OCaml dependencies, then indeed you can deploy them with a wrapper script that sets LD_LIBRARY_PATH, or you can use rpath, or you can dlopen your libraries, if it makes sense for you. In any case I strongly suggest you not to treat libc in a such way, i.e., do not try to install your own version of libc.

How to package or deliver updated shared libraries with an application

You wouldn't want to modify LD_LIBRARY_PATH. You could use an rpath in your libraries/binaries though.

Alternatively, if your version has a different soversion then there isn't any conflict and linking will just work and you can install them into the normal locations.

That being said I wouldn't do that and would probably go with the package-local lib directory and use an explicit rpath to that location.

What is the prefered way to publish a binary-only application for multiple Linux distributions?

You should have a look at the Linux Standard Base. It's designed specifically to help people in your position. It defines an environment that 3rd party application developers can rely upon - so there's set version of libc and other libraries, and certain programs and directories live in known places. All of the main Linux distribution support LSB.

That said, you should still probably package the result specifically for each major distribution - just so that your customers can manage your app with their familiar package management tools.

What is the difference between LD_PRELOAD_PATH and LD_LIBRARY_PATH?

LD_PRELOAD (not LD_PRELOAD_PATH) is a list of specific libraries (files) to be loaded before any other libraries, whether the program wants it or not. LD_LIBRARY_PATH is a list of directories to search when loading libraries that would have been loaded anyway. On linux you can read man ld.so for more information about these and other environment variables that affect the dynamic linker.

What is the best way to look for ELF Shared Libraries under linux in C

/usr/lib64 and /lib64 for 64-bit binaries or /usr/lib and /lib for 32-bit binaries, than paths taken from /etc/ld.so.conf and included configs

From man ldconfig

ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories, /lib and /usr/lib (on some 64-bit architectures such as x86-64, /lib and /usr/lib are the trusted directories for 32-bit libraries, while /lib64 and /usr/lib64 are used for 64-bit libraries).

The cache is used by the run-time linker, ld.so or ld-linux.so.

...

/etc/ld.so.conf File containing a list of directories, one per line, in which to search for libraries.

Note that this info is for openSUSE, other distros may use different paths.

---

Related Topics