6

I'm working on a plain X11 app.

By default, my app only requires libX11.so and the standard gcc C and math libs. The App can extend features with Xfixes, Xrender and ALSA sound system. However, these (Xfixes, Xrender and ALSA) feature are optional.

To achieve this behavior, I am using run time loading i.e., libXfixes, libXrender and libasound shall be dlopen()ed.

Hence the App can function in absence of such libraries.

Now my question: What library names should I use when calling dlopen()?

I've observed that these differ from distro to distro.
For example, on openSUSE 11, they're named the following:

  • libXfixes.so
  • libXrender.so
  • libasound.so

On Ubuntu, however, the names have a version number attached, like this:

  • libXfixes.so.3
  • libXrender.so.1
  • libasound.so.2

So trying to open "libXfixes.so" would fail on Ubuntu, although the lib is obviously there. It just has a version number attached. So how should my app handle this?

Should I let my app scan /usr/lib/ first manually to see which libs we have and then choose an appropriate one? Or does anyone have a better idea?

genpfault
  • 51,148
  • 11
  • 85
  • 139
Andy
  • 63
  • 1
  • 3

2 Answers2

2

You should dlopen using the library's SONAME. You can see that by using readelf -d [libname].

For example, on one of my Fedora Linux machines the SONAME of the C library is libc.so.6.

The symlinks from the .so names to the .so.6 names are not guaranteed. Those symlinks are only needed for compiling software and are usually not installed on systems without the development packages.

You would not want to end up loading a version with a different number anyway, because the number changes indicate major API differences.

Zan Lynx
  • 53,022
  • 10
  • 79
  • 131
  • Most libraries are backwards compatible which means that a library with a higher soname should work. Say you write a program that dlopens `libc.so.6`. Then the libc developers make a major update and releases `libc.so.7`. Now your program will needlessly break because the soname doesn't match. – Björn Lindqvist Jul 10 '14 at 10:51
  • 1
    @BjörnLindqvist: no, most libraries *aren't* backwards compatible. Where did you get that idea? And if they are compatible then they don't change the major version number. GNU libc has been on 6 for a long time now. – Zan Lynx Jul 10 '14 at 17:12
  • You can include and use the provided macros for loading the various glibc shared libraries. Other packages may do similar things to provide which name of library to load. See "man dlopen" for an example. – Carlos O'Donell May 02 '16 at 18:53
-1

From what I have learned, you just dlopen() (for example) "libXfixes.so", which is most likely a symlink to the newest file "libXfixes.so.3" anyways, in a similar fashion to this one:

$ file /usr/lib/libalpm.so
/usr/lib/libalpm.so: symbolic link to `libalpm.so.4.0.3'

A quick overview of my "/usr/lib/" shows, that almost EVERY library in there is symlinked to it's newest ".X" numbered file, and I'm sure that's how it's done on other distribtuions, too.

Only if you need a specific version of the library, you explicitly name the version "libXfixes.so.2" for example.

LukeN
  • 5,590
  • 1
  • 25
  • 33