On Thu, Apr 17, 2008 at 01:44:55AM -0500, Manoj Srivastava wrote: > >> > What if the library says "You must call /usr/bin/foo during build"? > >> > >> How does the library say that? Why can't I just have gcc -o baz baz.c > >> -lfoo > >> > >> How can the library make that not work? > > > By not shipping the libraries in /usr/lib: > > >> pkg-config --libs valgrind > > -L/usr/lib/valgrind/amd64-linux -lcoregrind -lvex -lgcc > > And how exactly does this prevent me from doing: > baz: baz.c > gcc -o baz baz.c -L/usr/lib/foo/amd64-linux -lfoo By changing the paths and library names often. If upstream says pkg-config is the only supported thing, and all other methods, in particular direct linking, should be expected to break every time a new version comes out, then pkg-config is indeed how things must be done. If you don't, you get an FTBFS in a binNMU, which would not have been there if you would have used upstream's build system. Of course it is always possible for a package maintainer to divert from his upstream, and in some cases it is a very good idea, too. But when you do this, you're taking over a part of upstream. Only the library package maintainer can do this (not the maintainer for packages linking to the library). If you want to guarantee a stable interface when using -l for your library, even when upstream doesn't, go right ahead. But it's not the only way, and if a library package maintainer follows his upstream in requiring pkg-config, then packages depending on his -dev package will _need_ to use that method. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
Attachment:
signature.asc
Description: Digital signature