Re: pkg-config and static builds

[Werner LEMBERG]

> 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.

It is unrealistic to expect that all libraries needed by a package are
manually compiled by the user so that all `.la' files are present.
Additionally, there are zillions of packages that don't use libtool.

> 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.

Let's assume that .pc files are correct, otherwise this discussion
leads to nowhere.  In addition, if you install a library from the
source code, a proper .pc file is also installed in most cases.

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

Hmm.  I wonder whether the libtool team is going to improve that.
Using, say, LDFLAGS_STATIC instead of LDFLAGS (if defined) for static
builds would not be too difficult to implement, I reckon.

> 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.

Well, yes, this is exactly why I'm discussing this issue :-)

> 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.

I'm aware of that, too.

> 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.

Indeed.  However, how is that related to my request of having a
separate set of linker flags for *static* linking?


    Werner