Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Take a package like sqlite3:

http://packages.ubuntu.com/lucid/i386/libsqlite3-0/filelist
http://packages.ubuntu.com/lucid/i386/libsqlite3-dev/filelist

Note that the linker name (/usr/lib/libsqlite3.so) only appear in the -dev package. The same pattern holds true for almost all shared libraries. Why? Won't this confuse programs that tries to dynamically load sqlite3 using dlopen("libsqlite3.so") when that file is missing unless you have the -dev variant?

share|improve this question
    
It allows the OS to inform the binary of what version is installed, so it can select from multiple installed versions without conflicting. –  hbdgaf Apr 22 '13 at 21:16

1 Answer 1

The libsqlite3.so file is only a symbolic link to the fully versioned library file name, libsqlite3.so.0.8.6. At runtime, the dynamic loader only knows about the fully versioned library. This is true for most shared libraries. There are some libraries which are not versioned, and only available as libnspr4.so for example. However, such libraries are also packaged correctly, as appropriate.

Programs should not be trying to dlopen the non-versioned link of the library. If they wish to do that, they should instead use the libsqlite3.so.0 filename, for example, which is installed in the binary library package, rather than the accompanying -dev package. This way the program will continue working if sqlite3 breaks API compatibility at some point, and there is a libsqlite3.so.1 instead. Using libsqlite3.so.0 would ensure the program would use the API of the library which it was written to work with.

share|improve this answer
    
Thanks, so what you're saying is dlopen("libsqlite3.so") is a programming error and should always be dlopen("libsqlite3.so.0") instead? If so, do you have a references for that statement because I've seen lots of code trying to dlopen non-versioned shared libraries. –  Björn Lindqvist Apr 24 '13 at 12:59
    
It's certainly bad practice. I don't have a reference to point you to, but the problems with trying to load the one without the so version should be obvious. If you load libfoo.so, and require a symbol that is in libfoo.so.0 but was removed from libfoo.so.1, then your program will break when loading libfoo.so when it points to libfoo.so.1. –  dobey Apr 24 '13 at 19:10

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.