Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As an example, let's say I want to upgrade sqlite3. The version I have after (apt-get) updating and upgrading is 3.7.13. The most current version is 3.7.14. If I install the most current version from source, can I somehow know it won't break existing software on this computer? Is there some list of what software depends on what other software?

It's not really necessary with sqlite3, but I still want to know in general.

I'm running debian wheezy.

share|improve this question
Do you know about Debian's unstable ("Sid") and experimental repositories? In your example, libsqlite3 is packaged in unstable; so you could, with care, avoid compiling from source and possibly creating an untidy situation. – sr_ Dec 10 '12 at 7:53

Binary compatibility - ABIs and APIs

To understand why making updates may or may not break existing software on your machine, you should have a vague awareness of libraries' ABIs and APIs. See this related question on StackOverflow for more info.

Shared library versioning

Software is usually released with at least major and minor version numbers. I have read that generally, any ABI incompatibilities should only be introduced along with a change in major version number. So if you're upgrading between minor versions, you should generally be safe to just install the new version over the old.

Installed shared libraries should have a version number appended to the file name, and often this differs from the release version number. Other applications depending on that shared library will have been linked in when building the source code. The resulting binary should then use the dynamic linker to look for the right shared library, identified it by its major version number. (This is probably dependent on the linker used and there's probably an ld option, which allows you to specify minor version instead..)


Using libsqlite3-0 (3.7.13-1) as an example, I have one shared library file and two symbolic links pointing to that library:

> ls -l /usr/lib/x86_64-linux-gnu/libsqlite3.so*
lrwxrwxrwx 1 root root     19 Jun 14 14:05 /usr/lib/x86_64-linux-gnu/libsqlite3.so -> libsqlite3.so.0.8.6
lrwxrwxrwx 1 root root     19 Jun 14 14:05 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 -> libsqlite3.so.0.8.6
-rw-r--r-- 1 root root 692984 Jun 14 14:05 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6

So, how to tell if a library or executable has been linked against this library, and what version it depends on?

On Linux, use:

`ldd <filename>`

On OS X:

`otool -L <filename>`

For example, let's see what version of libsqlite3 Python's sqlite module needs, to function.

> ldd /usr/lib/python2.7/lib-dynload/_sqlite3.so | grep sqlite
        libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007fe32872c000)

So it only needs the major-version numbered symbolic link, and not the fully named and numbered shared library. Updates then, should just update the libsqlite3.so[.0] symbolic links to point to the new shared library.

Building a cutting-edge libsqlite from source would hopefully create a shared library with the same major version number. If not, you can always overwrite the symbolic link and point it to your desired version, test, and revert to system packages if/when necessary.


As you're using Debian, I thought I'd also mention that aptitude allows you to view "Packages which depend on libsqlite3-0 (267)" (and the same for any other package, too). Of course, if you've compiled a lot of applications from source, and haven't informed dpkg of this, then this list may not be exhaustive.

share|improve this answer

Take a look at the report on backward binary compatibility for the library here (or may be here). It's not OK to upgrade if there are some ABI breaks in the library between the compared versions.

Also your configuration of the library may differ from the distribution one (some specific options, that can force some changes in the ABI), so it's better to upgrade your libraries with the help of the package manager only.

Particularly the upgrade of the sqlite looks safe because of this report:

enter image description here

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.