[Zero-install-devel] Re: Linux binary compatibility

[Mike Hearn]

On Sat, 2004-02-28 at 20:30, Owen Taylor wrote:
> Please don't do *that* in *any* programs Makefile. If you are interested
> in this subject you should look at what Pango is doing to hide
> most of it's dependent libraries, and the --enable-explicit-deps
> command option.

Which program is this an option for? It's not in the info pages I have
here for ld, gcc nor libtool. Sorry if I missed them somehow....

> But I don't think pkg-config can do this automatically, for instance,
> while hiding pangoxft is probably right, hiding pango or GLib is almost
> certainly wrong, since Pango and GLib are  considered an integral parts
> of the GTK+ API. 

As a bit of background this topic came up as we had some problems with
libcurl. curl-config --libs spits out a ton of -l flags, including on
OpenSSL, which unfortunately is not a very stable library. The soname
used varies between even modern distributions. However, our program did
not use OpenSSL, it did not even care about SSL anywhere at all, so this
bogus DT_NEEDED entry was causing our program to fail for no good
reason. Removing the use of curl-config --libs and replacing it simply
with -lcurl fixed the issue.

So, while I'd agree that Pango and GLib are integral to the GTK+ API,
I'm not sure I'd agree that `pkg-config --libs gtk+-2.0` should always
give the equivelant of "-lpango -lglib", because bogus dependencies from
a binary to a library are:

a) pointless
b) a binary portability problem, as the OpenSSL issue showed.

OK, so this is a bad example because Pango, GLib and GTK+ are all well
maintained and very stable (not to mention released together) so it's
not going to cause problems in practice, but for other libraries it can
do. 

However, you don't seem to lose anything by only adding -l flags when
you explicitly use symbols from that lib. If you don't use anything from
the Pango namespace, then the fact that it's involved is purely an
implementation detail of GTK+, right? As implementation details of
libraries can change at any time, there's no need to have any
information about it in your binary.

> (On Linux, this actually doesn't matter much, because ld can follow
> shared dependencies, but on say Solaris, shared library dependencies are
> a run-time only thing. If you use a symbol from a library in your
> application, that library must be on the link line.)

Yeah. Even if you don't care about portability though for the sake of
sanity I think it's a good idea to explicitly give the library on the
link line anyway. Otherwise the library changes the library it uses
internally and suddenly your own app stops linking. The trick is to
ensure you have enough -l options and no more. 

thanks -mike