Hello Mike and all, below are listed the problems I see with pkg-config. I'm not submitting a patch to pkg-config right now. It's not because I do not want to be helpful; it's because though I see the problems, I'm not sure how the right fix looks like. 1) The most important one is this: $ pkg-config --libs blkid -L/lib -lblkid -luuid -ldevmapper The "-ldevmapper" option is not only redundant, it's very evil. Se below for a detailed explanation (let's call this "so-deps hell"). Karel proposes to add --as-needed (or -Wl,--as-needed) to *_LDFLAGS for dynamic linking to fix this. (configure has to check that --as-needed is available, of course.) My proposal would be to use hardwired "-lblkid -luuid" for dynamic linking and start using pkg-config only when/if it is really needed, ie. a real-world bug report arrives. 2) Second problem: As a disiplined citizen of the Automake world, you should put -l and -L options to *_LDADD and the rest to *_LDFLAGS. Though the pkg-config script has options which enable to solve this, Autoconf macros in pkg.m4 do not use them. One has to do something like: BLKID_LDADD=$(pkg-config --libs-only-l blkid)" "$(pkg-config --libs-only-L blkid) BLKID_LDFLAGS=$(pkg-config --libs-only-other blkid) It's a question whether the pkg.m4 macros should be used in configure.ac, or whether they shall serve only as an inspiration for our code. Roughly speaking, we would call AC_RUN_LOG([pkg-config --exists --print-errors blkid]) and check whether the --libs-only-* options are supported before the above assignments. But Karel suggests we use PKG_CHECK_EXISTS from pkg.m4 for this (that would include a version number check to ensure --libs-only-* are available). Yes, this cries for a fix in pkg.m4, but the fact that the old broken interface has to be maintained may complicate the situation... A note: Libtool was designed to handle this. But the implementation contains one fatal bug, which is one of the most important reasons why libtool was not generally adopted and why pkg-config gains popularity. It is very ironical that pkg-config contains exactly the same bug, which patiently waits to strike as soon as pkg-config gets accepted for lower level projects. And now the promised explanation of the "so-deps hell" -------------- Let me tell you the Libtool story first: One of the goals of Libtool was automatic handling of dependencies between libraries which is necessary for static linking and on many platforms also for dynamic libraries. So if a libhighfoo uses liblowfoo, the user should be able to do something like ./libtool link -lhighfoo without the need to know about -llowfoo. (And, of course, if future libhighfoo will use libNewBrilliantLowFoo, the command stays the same.) This goal was achieved by a simple tool: each libfoo.a and/or libfoo.so is accompanied by a libtool.la, which is a text file with basic information about the library, among other the list of pre-requisite libraries. So the above quoted command finds libhighfoo.la, finds out that liblowfoo is required and passes "-lhighfoo -llowfoo" to the linker. For the static build, this is good and enables the link. The same holds for dynamic linkers which are not able to handle dependencies of dynamic libraries. For GNU ld.so, which can handle dependencies of dynamic libraries, the -llowfoo is obviously redundant. But it seemed harmless at first. But there was a difference: the "-llowfoo" option causes a DT_NEEDED liblowfoo.so.1 to be engraved in the binary. Now imagine that lowfoo changes it's ABI in an incompatible way. Inevitably, highfoo has to be rebuilt against the new liblowfoo.so.2. But because all the programs using highfoo have the unfortunate DT_NEEDED record in their headers, they all have to be rebuilt too. If the lowfoo is something like openssl, we have to rebuild half of the whole Debian. No wonder that Debian immediately generated a policy that *.la files may not be stored into the -dev package, effectively switching off the Libtools dependency handling. (I'm a Fedora developer, and there is a rule against *.la, too.) If you have groked the above story, it should be clear that having -ldevmapper in mount_LDADD is the first step on the way to hell. Happy hacking, Stepan - To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
