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 (gary@xxxxxxx) _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
