Re: The problem with pgk-config

[Gary V . Vaughan]

[RESEND - apologies if you see this twice... no echo from the list after 10 
hours or so]

On 1 Aug 2010, at 04:31, Bob Friesenhahn wrote:
> On Sat, 31 Jul 2010, Ralf Wildenhues wrote:
>> 
>> I'd rather avoid (3), and I know (2) is going to be quite some work, but
>> should be done.  What things go wrong with pkg-config?  (Please adjust
>> the Subject: when replying to this, thanks!)
> 
> The main problem I find with pgk-config is that it has nothing to do with the 
> libraries the linker actually finds.  Instead it is producing an incantation 
> based on some other paths (PATH and PKG_CONFIG_PATH). This is particularly a 
> problem on a stable system like Solaris 10 where one wants to use some 
> system-provided libraries, yet use more modern libraries from a different 
> path.  This may result in two pkg-config directories which contain 
> non-dependent libraries from different vintages.  The result is that the 
> wrong libraries may be used.
> 
> Libtool works at a lower level (more similar to the linker) so that it knows 
> the actual libraries which were used.
> 
> Regardless, pkg-config only proposes configuration information while autoconf 
> tests to make sure that it really works.

Agree with all of the above.

pkg-config is especially onerous when one wants to maintain a separate GNU Stow 
like arrangement of open source packages maintained separately to the vendor 
tools -- where each package gets it's own installation directory to make 
concurrent installation of multiple package versions, and upgrading of 
individual packages as easy as possible.  In this case, when linking a utility 
that has a moderately deep deplib stack and which wants to use pkg-config, you 
have to either build a staging directory with links to each of the .pc files, 
or else construct a bespoke unreasonably long PKG_CONFIG_PATH setting 
per-package.  In itself, not so bad, except that (unlike libtool or an ELF-like 
linker), pkg-config forces you to manually unwind the entire deplib stack 
before it will work to ensure that you didn't forget any indirect deplib that 
is not even used by the utility at the top of the stack that you are trying to 
link.

For example, with each package is installed to /opt/fsw/<package>-<version>, 
the PKG_CONFIG_PATH for monodevelop turns out to be:

PKG_CONFIG_PATH="/opt/fsw/boo-0.7.6/lib/pkgconfig:\
/opt/fsw/fcpackage-0.22/lib/pkgconfig:\
/opt/fsw/gecko-sharp-2.0-0.12/lib/pkgconfig:\
/opt/fsw/gettext-0.17/lib/pkgconfig\
/opt/fsw/gnome-2.22/lib/pkgconfig:\
/opt/fsw/gtk-sharp-2.0-2.4.3/lib/pkgconfig:\
/opt/fsw/gtksourceview-sharp-2.0-0.11/lib/pkgconfig:\
/opt/fsw/libart_lgpl-2.3.16/lib/pkgconfig:\
/opt/fsw/libatk-1.9.1/lib/pkgconfig:\
/opt/fsw/libglade-2.5.1/lib/pkgconfig:\
/opt/fsw/libglib--2.6.5/lib/pkgconfig:\
/opt/fsw/libgtk+-2.6.5/lib/pkgconfig:\
/opt/fsw/libpango-1.8.2/lib/pkgconfig:\
/opt/fsw/libttf-2.1.9/lib/pkgconfig:\
/opt/fsw/libxml2-2.6.22/lib/pkgconfig:\
/opt/fsw/mono-1.2.4/lib/pkgconfig:\
/opt/fsw/libz-1.2.3/lib/pkgconfig:\
/opt/fsw/monodebugger-0.50/lib/pkgconfig}:\
/opt/fsw/libiconv-0.12/lib/pkgconfig"

Luckily, we installed all the GNOME packages under gnome-2.22, otherwise there 
would have been another dozen entries to take into account in addition to 
these, and even more luckily only GNOME related packages seem to have adopted 
pkg-config, otherwise there would also have been another dozen entries for the 
other libraries (jpeg, tiff, etc) that the linker knows I used when building 
libgtk+ but for which there is no .pc file depended on by libgtk+-2.0.pc.

Also, don't forget that this isn't only an annoyance for the packages at the 
top of the stack, but also has to be addressed over and over again for every 
pkg-config using library all the way down the stack as those libraries are 
built and installed.  Not to mention that the package maintenance process now 
includes a mostly unnecessary (but for pkg-config) step of keeping track of 
PKG_CONFIG_PATHs incase we want to relink something later.

I'm still somewhat disgruntled that all of the effort that was spent on 
pkg-config (not to mention the pain one has to endure when using it!) wasn't 
spent on a patch for libtool to store and extract the flags that pkg-config 
wants to manage.  There's a huge overlap already, and libtool is already 80% of 
the way to providing the functionality of pkg-config, as well as having all the 
infrastructure in place already to avoid at least the problem I outline above.

The one fly in the ointment is that a significant selection of libtool users 
seem to find life more convenient when they delete all installed .la files, 
which would make folding in pkg-config like functionality impossible.  I 
confess that I haven't really tried to understand why that is, since I always 
leave the .la files in place, and they have never given me any problems 
personally.

Cheers,
-- 
Gary V. Vaughan (address@hidden)