How to upgrade a shared library to a newer version when installing from source code?

Question

I am installing an application from source code and it requires a shared library which I'll call abc. The configure process finds a libabc.so symlink in /usr/lib that points to a 0.23 version of abc that is in /usr/lib folder. However, the project I am installing, requires the latest, 0.24 version of abc. I downloaded source code for abc and follwed the installation process: (configure, make, make install). The 0.24 version of abc is now installed in /usr/local/lib. However the configure utility for the application I am installing still complains that abc version 0.23 is not enough to go ahead with installation. How do I upgrade the abc installed on my system from 0.23 to 0.24? As a potential hack I guess I could change the symbolic link in for /usr/lib/libabc.so to point to the file in /usr/local/lib , but I don't feel that it is a clean solution. Another possiblity is to tell the installer somehow to look for shared libraries also in /usr/local/lib. What is the best way to proceed?

Note that /usr/local/lib is listed in one of the configuration files in /etc/ld.so.conf.d/.

This is not recommended, see: Using Awesome window manager on CentOS 7 — eyoung100, Jan 04 '15 at 22:45
Use binary packages. You might be able to use backports. Try to avoid local installs for system libraries, or even regular non-critical libraries. — Faheem Mitha, Jan 04 '15 at 23:25

score 1 · Accepted Answer · edited May 23 '17 at 12:39

Basically, if this is an upgrade, and your old program can also rely on 0.24, I would recommend overwritting your previous library install with the new one (which is what we call "upgrading" at a higher level). While it would be better to manage all that with a package manager, you may be stuck with libraries the source of which are not available in your distribution's repositories.

By default, libraries which are built manually go to /usr/local/lib, but that's decided by the configure script. If is possible, however, to change that:

$ ./configure --prefix=/usr
$ make
$ sudo make install

By using /usr as a prefix, libraries objects will go to /usr/lib, headers to /usr/include, configuration to /usr/etc and so on... This should basically overwrite your previous version of the library, since the .so files of both versions should have the same name if correctly maintained by the developper.

Now, if you want to keep 0.23 (for instance, if your first program does not handle 0.24), you'll have to specify a path to the new library (at /usr/local) to your last configure script (the one associated with the program requiring 0.24).

Most of the time, configure scripts providing switches to specify paths to libraries, so that people in such situations can be specific when installing. A list of these switches should be visible through ./configure --help. In your case, the standards dictate that such a switch should be called --with-libabc or --with-abc:

$ ./configure --with-libabc=/usr/local/lib

A good example of that is PHP's libxml's dependency:

$ ./configure --with-libxml-dir=...

Some scripts may also provide a --with-libdir switch which allows you change the library search path completely:

$ ./configure --with-libdir=...

You might also want to have a look at this Stack Overflow question about the config.site file.

How to upgrade a shared library to a newer version when installing from source code?

1 Answers1