CODEWITHSUNDEEP
linuxelfdynamic-linking
Juan
Juan

Reputation: 3775

Link against symlink instead of soname

I have an linux application, which on the linker line links against: libpython2.6.so

This ultimately resolves to libpython.2.6.so.1.0

/usr/lib/libpython2.6.so -> libpython2.6.so.1
/usr/lib/libpython2.6.so.1 -> libpython2.6.so.1.0

Which has SONAME embedded in it so that I am stuck with it linking against the fully versioned name.

 g++ foo.cc /usr/lib/libpython2.6.so
 ldd ./a.out | grep python
        libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0x00007fd36f7ab000)

This means that my application will ultimately break if there is ever a libpython2.6.so.1.1. Is there anyway to force my application to use the generic name libpython2.6, instead of libpython2.6.so.1.0?

I use such a small set of the python API, that I think I should be safe linking against a more generic version name of the library.

Upvotes: 1

Views: 2722

Answers (2)

Huang F. Lei
Huang F. Lei

Reputation: 1865

Have a look at ``3.1.1. Shared Library Names '' in http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html , this may help you understand the naming method of share library.

Every shared library has a special name called the soname''. The soname has the prefixlib'', the name of the library, the phrase .so'', followed by a period and a version number that is incremented whenever the interface changes (as a special exception, the lowest-level C libraries don't start withlib''). A fully-qualified soname includes as a prefix the directory it's in; on a working system a fully-qualified soname is simply a symbolic link to the shared library's ``real name''.

Every shared library also has a ``real name'', which is the filename containing the actual library code. The real name adds to the soname a period, a minor number, another period, and the release number. The last period and release number are optional. The minor number and release number support configuration control by letting you know exactly what version(s) of the library are installed. Note that these numbers might not be the same as the numbers used to describe the library in documentation, although that does make things easier.

In addition, there's the name that the compiler uses when requesting a library, (I'll call it the ``linker name''), which is simply the soname without any version number.

Upvotes: 1

Martin v. Löwis
Martin v. Löwis

Reputation: 127587

Don't worry about the SO version of libpython2.6 increasing. It will never increase; there won't be any further bugfix releases to 2.6, and even if there were, the SO version would not be increased.

You should rather worry about libpython2.6 going away in future releases of the system (to be replaced by libpython2.7). There isn't any good solution to that, yet; with PEP 384, you will be able to link with libpython3.so.

Upvotes: 1

Related Questions