Re: Static linking: pkgconfig vs libtool
On Fri, 19 Nov 2010 at 22:30:09 +0100, Dmitry Katsubo wrote:
> * Some libraries (e.g. GraphicsMagick) does not provide the list of
> libraries for statis linking via .pc (compare 'pkg-config --static
> --libs GraphicsMagick++' and 'GraphicsMagick++-config --libs'). Should
> it be fired as a bug for GraphicsMagick package?
I think so; the solution to that bug is to add the extra libraries listed by
GraphicsMagick++-config to Libs.private in GraphicsMagick++.pc (or if they
have a .pc file themselves, add the name of that .pc file to Requires.private
instead).
> * 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)
The choice of .pc filename is generally a decision for upstream, in the same
way as the name of a C/C++ library or the name of a header file. It's part
of the library's API, and distributions shouldn't generally change it (which
would result in depending packages' build systems working on some
distributions but not others). Renaming an upstream-supplied .pc file is only
appropriate if it would fix even worse breakage than it causes.
Upstreams are only meant to change the .pc filename when they make an
incompatible change to the API - if XFCE 4 is still compatible with the API
(but not necessarily the ABI) of the earliest version that had xfprint-1.0.pc,
then it shouldn't be renamed.
Having a distribution-specific ABI (like a Debian-specific change to the SONAME
of a C/C++ library) is unfortunate, but tolerable, because binaries for one
distribution aren't usually expected to be portable to another without taking
special steps. Having a distribution-specific API is worse, because it means
*source code* isn't portable between distributions.
Regards,
S
Reply to: