On Mon, Dec 10, 2007 at 06:47:15PM +0000, Michael Poole wrote: > Steve Langasek writes: > > > On Sun, Dec 09, 2007 at 07:23:00PM +0100, Josselin Mouette wrote: > > > >> Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit : > >> > Just curing the symptoms instead of the problems will not help to get > >> > there any sooner. > > > >> What if there is no problem? > > > >> For example, pkg-config --libs gtk+-x11-2.0 will return, among others, > >> -lglib-2.0 and -lm. And this is perfectly intentional. > > > > Just because it's intentional doesn't mean it isn't absurd and wrong. > > What happens for a user who (however absurd or insane he might be to > try this with gtk+) tries to link his application statically? > > Perhaps the "absurd and wrong" part is that pkg-config does not > provide a way to distinguish between use cases, and that the name for
Wrong, please read pkg-config(1) and think again.
$ pkg-config tokyocabinet --libs
-ltokyocabinet
$ pkg-config tokyocabinet --libs --static
-ltokyocabinet -lz -lpthread -lm -lc
$ grep Libs /usr/lib/pkgconfig/tokyocabinet.pc
Libs: -L${libdir} -ltokyocabinet
Libs.private: -lz -lpthread -lm -lc
pkg-config *is* perfectly suited for that matter actually, and
"broken" pkgconfig upstreams are this trivial to fix. My upstream for
tokyocabinet uses in a tokyocabinet.pc.in:
Libs: -L${libdir} -ltokyocabinet @LIBS@
the fix is just to put the @LIBS@ onto Libs.private and be done with it.
Upstreams using pkg-config are actually the first _easy_ targets to fix
the dependency issues _they_ generate in others binaries. And there is
no reason no to fix those when it's easy to do so.
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgpCfl6oQ2bbd.pgp
Description: PGP signature
