[suggest] Re: suggest Digest, Vol 60, Issue 13
peak at argo.troja.mff.cuni.cz
Wed Jun 23 20:28:31 CEST 2010
On Mon, 21 Jun 2010, Yury V. Zaytsev wrote:
> Yep. No, usually the ABI is not upward compatible.
Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.
"Applications compiled for 4.0, 4.1, 4.2, and 4.3 will continue to run
> I am not familiar with dynamically linked libraries management on Linux.
> What do you mean by "change the soname"? Shall I just rename the so to
> libQtCore.so.4.5.4 and remove the synlinks?
ELF dynamic libraries include their "true names" called "soname" (I guess
it stands for "shared object name") in their .dynamic section.
When you link a program with a dynamic library using "-llibrary" the
linker finds "library.so", reads its soname, and adds dependency to the
soname (rather than to "library.so") to the resulting executable file.
A dynamic library having a certain soname is supposed to be binary
compatible with any program depending on the same soname in the sense that
either the program works correctly or it fails to start due to missing
A common convention is to use "library.so.1" (where 1 is the generation of
ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the
library) as a filename, and to let ldconfig symlink soname to filename.
> > It does not scale up very well, IMHO.
> Oh really? What would be the potential problems that I'd face?
Qt is a big library. Much bigger than SQLite or libcurl. You'd get
1. bloated source packages, 2. slow rebuild times, and 3. bloated binary
packages if you bundled a private copy of Qt with every package needing
Issues 1 and 2 might be eliminated if there was a standalone
static-library-only devel package of Qt (and perhaps a small runtime
package if any data files are needed).
Pavel Kankovsky aka Peak / Jeremiah 9:21 \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /
More information about the users