[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Static linking: pkgconfig vs libtool

On 19.11.2010 22:51, Russ Allbery wrote:
> Dmitry Katsubo <dma_k@mail.ru> writes:
>> The first problem I faced is that it is difficult to explore what should
>> be the list of libraries for static linking (as I have to provide the
>> list of libraries which are direct dependencies as well as indirect). I
>> know this problem is solved with libtool (which consumes the information
>> from *.la) and with pkg-config (which consumes the information from
>> *.pc). The problems I faced:
>> * General question. What is the current trend: to use libtool or
>> pkg-config? For me it is easier to use pkg-config CLI, rather then
>> re-write autoconf scripts to fit libtool ideology (maybe I don't need
>> to, fixme).
> pkg-config is much superior to libtool, since libtool includes all the
> libraries on dynamic links as well, which creates unwanted shared library
> dependencies and causes other problems.  Because of that, the trend in
> Debian is to empty that information from libtool *.la files or not ship
> them at all, making them useless for static linking information.
>> * 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 it's reasonable to consider that a bug, although it's probably a
> minor one and it may be closed wontfix if the GraphicsMagick maintainers
> aren't interested in supporting static linking.  (A lot of upstreams just
> don't care about static linking and aren't willing to support it.)
>> * 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)
> Er, what does an agreement for .NET/CLI have to do with pkg-config files
> for libraries written in C?  I don't see any relevance of that packaging
> documentation to the libraries you list.
> The pkg-config configuration file name is not, in general, going to be
> determinable from the Debian package name.

Russ, thank you for comments. To answer your question I quote only one
important section from the document I've referred:

=== quote ===
3.2.4 pkg-config File

Many libraries deliver a .pc file for use by the pkg-config helper
utility, which aids other libraries and applications to link against

All GAC library packages should have a pkg-config .pc file located in
/usr/lib/pkgconfig. The filename must be named: package-X.Y.pc including
the versioning. The version must reflect the same X.Y version as the
package name. There must also be a symlink without the version to the
latest version, as follows: from package.pc to package-X.Y.pc
=== end of quote ===

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

If *.pc files are not following the version of the package, I wonder how
versions should be assigned and incremented, and what are the criteria
for that.

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.

So I wonder, if there are any polices, that regulate above mentioned,
similar to .NET/CLI policies I've quoted.

Thank you in advance!

With best regards,

Reply to: