2

I developed a C program requiring some dynamic libraries, most notably libmysqlclient.so, which I intent to run on some remote-hosts. It seems like I have the following Options for distribution:

  1. Compile the program static.
  2. Install the required dependencies on the remote host
  3. Distribute the dependencies with the program.

The first option is problematic as I need glibc-version at runtime anyway (since I use glibc and libnss for now).

I'm not sure about the second option: Is there a mechanism which checks if a installed library-version is sufficient for a program to run (beside libxyz.so.VERSION). Can I somehow check ABI-compatibility at startup?

Regarding the last Option: would I distribute ALL shared-libraries with the binary, or just the one which are presumably not installed (e.g libmysqlclient, but not libm).

Apart form this, am I likely to encounter ABI-compatibility problems if I use a different compiler for the binary then the one the dependencies were build with (e.g binary clang, libraries gcc)?

dlmeetei
  • 9,905
  • 3
  • 31
  • 38
hex
  • 23
  • 2
  • Build packages (`.deb`, `.rpm`) that specify the correct dependencies, so the package manager will install them automatically. –  Jul 20 '17 at 09:59

1 Answers1

3

Version checking is distribution-specific. Usually, you would package your application in a .deb or .rpm file using the target distribution's packaging tools, and ship that to users. This means that you have to build your application once for each supported distribution, but there really is no way around that anyway because different distributions have slightly different versions of libmysqlclient. These distribution build tools generate some dependency version information automatically, and in other cases, some manual help is needed.

As a starting point, it's a good idea to look at the distribution packaging for something that relies on the MySQL/MariaDB client library and copy that. Maybe inspircd in Debian is a good example.

You can reduce the amount of builds you need to create and test somewhat by building on the oldest distribution versions you want to support. But some caveats apply; distributions vary in the degree of backwards compatibility they provide.

Distributing dependencies with the program is very problematic because popular libraries such as libmysqlclient are also provided by the base operating system, and if you use LD_LIBRARY_PATH to inject your own version, this could unintentionally extend to other programs as well (e.g., those you launch from your own program). The latter risk is still present even if you use DT_RUNPATH (via the -rpath linker option), although it is somewhat reduced.

A different option is to link just application-specific support libraries statically, and link base operating system libraries dynamically. (This is what some software collections do.) This does not seem to be such a great choice for libmysqlclient, though, because there might be an expectation that its feature set is identical to the distribution (regarding the TLS library and available configuration options), and with static linking, this is difficult to achieve.

Florian Weimer
  • 32,022
  • 3
  • 48
  • 92
  • You can use `rpath` with `$ORIGIN` to have your application look for libraries in a path relative to the application's directory first, this is an option for distributing all dependencies and the result should be installed somewhere below `/opt`. -- but I always prefer a package in the distribution's package-format. –  Jul 20 '17 at 10:18
  • This can still cause problems if you `dlopen` anything from the operating system, including the implicit `dlopen` performed by the Name Service Switch (`getpwnam` and friends). The latter shouldn't be using `libmysqlclient`, of course, but you never know … – Florian Weimer Jul 20 '17 at 10:21
  • Well, as long as you don't distribute anything that's needed for something different you `dlopen()`, you should be fine, and there are some Linux software packages actually using this. As I said, I don't like this solution very much, it's just for completeness. –  Jul 20 '17 at 10:23
  • See also https://stackoverflow.com/questions/25979778/forcing-or-preventing-use-of-a-particular-minor-version-of-libstdc – Bruce Adams Oct 26 '17 at 16:57