[Top][All Lists]

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

Re: pkg-config and static builds

From: Bob Friesenhahn
Subject: Re: pkg-config and static builds
Date: Mon, 3 Mar 2014 09:24:29 -0600 (CST)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

On Mon, 3 Mar 2014, Werner LEMBERG wrote:

it seems it has been already discussed that libtool should use a
different set of link flags if compiling a static library, especially
for libraries that come without a corresponding `.la' file, cf. this

Such a feature would be useful in combination with `pkg-config', which
has the `--static' command line option to give such a different set.

What's the current state?  As an example, let's assume that my library
uses libpng.  If I'm going to statically link to it, I need to add
`-lz' and `-lm'.  From where do I get this information for static
linking if I want to use libtool for building my own library?  I've
read that it would be better to not specify `-lz' and `-lm' while
building a shared library to avoid built-in references.

If the files are deleted, then you are on your own and your configure script can only make an educated guess based on experience and test those guesses. Guessing may be improved by using pkg-config ("manually" as you describe). Depending entirely on pkg-config is not wise since it is an add-on which is not part of the autotools framework and not uniformly maintained. If an end user installs his own libraries from source code (GNU still wants to support using source code), then the pkg-config information may not be correct for the end-user's build.

Nothing has changed in libtool since the discussion you refer to.

Static libraries do not have implicit dependencies (without benefit of the .la files) and they do not support library dependency versioning either. Static libraries are normally linked directly into the application being built and not into other libraries. Dependencies must be fully specified in order to avoid linkage failure. This makes static libraries much more fragile and problematic than using shared libraries.

Please note that there are some major operating systems that require that dependencies be fully specified while linking a shared library. An approach which works for GNU/Linux may fail on other systems.

Without an organization dedicated to making sure that it works (as most GNU/Linux distributions do have), it is not feasable to depend on shared library implicit dependencies. Successful implicit dependencies are the outcome of careful planning, design, and testing.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]