Re: Static linking: pkgconfig vs libtool
On Mon, 22 Nov 2010 at 16:18:52 +0100, Dmitry Katsubo wrote:
> On 19.11.2010 22:51, Russ Allbery wrote:
> > Dmitry Katsubo <dma_k@mail.ru> writes:
> >> * Some libraries (e.g.) do not follow the agreement for .NET/CLI
> >> (http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-pkg-config-file)
> >> which I think is also good to follow for common libraries:
> >> - xfprint4-4.6.1 package contains xfprint-1.0.pc (expected: xfprint4.pc
> >> or xfprint4.pc -symlink-> xfprint4-4.6.1.pc)
> >> - libxml2-dev package contains libxml-2.0.pc (expected: libxml2.pc or
> >> libxml2.pc -symlink-> libxml2-2.7.7.pc)
Bear in mind that version numbering in .NET/CLI appears to be much more
consistent between packages than version numbering in the rest of the world:
http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-gac-naming-versioning
For libraries that don't follow that convention (the vast majority), the .pc
conventions from that document aren't necessarily going to be appropriate
either.
> What I think is important, that X.Y somehow correlates with package
> version. OK, it could be "API version", but API might not change, while
> some important information changes (e.g. the list of static libraries).
> For example,
> a) libtiff-1.0 is linked against libjpeg-1.0
> b) libtiff-1.1 is linked against libjpeg-1.1 and also libm.
>
> Obviously, libtiff-1.0 and libtiff-1.1 should provide libtiff-1.0.pc and
> libtiff-1.1.pc correspondingly, even if libtiff's public API has not
> changed.
I don't think the sentence starting "Obviously" is necessarily true. There are
(at least) two ways in which libtiff might use libjpeg and libm:
1) objects from the lower-level library (libjpeg/libm here) appear in the API
of the higher-level library (libtiff), so incompatible changes to the
lower-level library are likely to be an incompatible change to the
higher-level library
2) the higher-level library encapsulates the lower-level library completely,
and users of the higher-level library only need to know about the
lower-level library at all if they're linking statically
For an example of (1), consider KDE depending on Qt. If Qt 5 is released with
QString changing from UTF-16 to UTF-8, it'll break all QString-based KDE APIs.
This sort of dependency is, admittedly, much more common than the other.
For an example of (2), consider Phonon depending on GStreamer and/or VLC; it
presents the same C++ API regardless of the choice of lower-level library.
> What is also important, that there is a symlink without the version,
> e.g. libtiff.pc --> libtiff-1.1.pc (points to the latest installed
> version). It helps to use the "latest available" information, without a
> need to discover actual version.
I don't think that's appropriate in all cases. If (say) libfoo 1.0 and
libfoo 2.0 are extensively incompatible, then saying "my software requires
libfoo" or even "my software requires libfoo >= 0.9" is unhelpful, because it
won't compile after you've upgraded to libfoo 2.0.
Having an unversioned symlink also makes it impossible to install libfoo 1.0
and 2.0 at the same time (perhaps you have an old app which requires libfoo 1.0
and hasn't been ported yet).
A common way to fix this is parallel-installability - effectively, you treat
the incompatible versions as entirely different libraries (which happen to
have the same author, website etc. and remarkably similar names). See
http://ometer.com/parallel.html for details about this.
Real-world examples include Gtk 1.2 and 2.0 (1.2 has finally been removed from
Debian), and Qt 3 and 4.
Regards,
Simon
Reply to: