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

Question

I have an application that relies on Qt, GDCM, and VTK, with the main build environment being Qt. All of these libraries are cross-platform and compile on Windows, Mac, and Linux. I need to deploy the application to Linux after deploying on Windows. The versions of vtk and gdcm I'm using are trunk versions from git (about a month old), more recent than what I can get apt-get on Ubuntu 11.04, which is my current (and only) Linux deployment target.

What is the accepted method for deploying an application that relies on these kinds of libraries?

Should I be statically linking here, to avoid LD_LIBRARY_PATH? I see conflicting reports on LD_LIBRARY_PATH; tutorials like this one suggest that it's the 'right way' to modify the library path to use shared libraries through system reboots. Others suggest that I should never set LD_LIBRARY_PATH. In the default version of GDCM, the installation already puts libraries into the /usr/local/lib directory, so those libraries get seen when I run ldd <my program>. VTK, on the other hand, puts its libraries into /usr/local/lib/vtk-5.9, which is not part of the LD_LIBRARY_PATH on most user's machines, and so is not found unless some change is made to the system. Copying the VTK files into '/usr/local/lib' does not allow 'ldd' to see the files.

So, how can I make my application see VTK to use the libraries?

On windows, deploying the dlls is very straightforward, because I can just include them in the installer, and the application finds them because they are in the local directory. That approach does not work in Linux, so I was going to have the users install Qt, GDCM, and VTK from whatever appropriate source and use the default locations, and then have the application point to those default locations. However, since VTK is putting things into a non-standard location, should I also expect users to modify LD_LIBRARY_PATH? Should I include the specific versions of the libraries that I want and then figure out how to make the executable look in the local directory for those libraries and ignore the ones it finds in the library path?

Answer 1

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.

Answer 2

In general, you're best off depending on the 'normal' versions of the libraries for whatever distribution you're targetting (and saying you don't support dists that don't support recent enough versions of the lib), but if you REALLY need to depend on a bleeding edge version of some shared lib, you can link your app with -Wl,-rpath,'$ORIGIN' and then install a copy of the exact version you want in the same directory as your executable.

Note that if you use make, you'll need $$ in the makefile to get a single $ into the argument that is actually sent to the linker. The single qutoes are needed so the shell doesn't munge things...

Answer 3

Well, there are two options for deploying Linux application.

The correct way:

• make a package for your app and for the libraries, if they are so special, that they can't be installed from standard repositories

• There are two major package formats. RPM and DEB.

The easy way:

• make a self-extract file that will install the "windows way" into /opt.

• You can have libraries in the same directory as the executable, it's just not the preferred way.