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 madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpozilaOpRgc.pgp
Description: PGP signature