Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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 3.7.14.1 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
add comment

1 Answer

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..)

libsqlite3

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.


Aptitude

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
add comment

Your Answer

 
discard

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.