[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The problem with pgk-config
From: |
Gary V. Vaughan |
Subject: |
Re: The problem with pgk-config |
Date: |
Sun, 1 Aug 2010 15:05:12 +0700 |
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)