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

[Owen Taylor]

On Sat, 2004-02-28 at 16:02, Mike Hearn wrote:
> 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....

It's not a standard tool option, it's a configure option for Pango
and GTK+. By default Pango and GTK+, if they see that the platform
has shared library dependencies export a minimal set of dependencies
(Which involves things like sed-jobbing dependencies_libs out of
.la files.)

But you can turn on full dependencies with --enable-explicit-deps
if you have a need. So, mentioning it was basically a shorthand
for the part of the configure file you should look at.

> > 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.

Hiding internal dependencies is definitely a good idea, which is why we
do it for Pango; but my point is that there are also non-internal
dependencies, so pkg-config can't just summarily strip out -l flags
on platforms with shared libraries.

> 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.

The GTK+ documentation include lots of GLib and Pango calls; many
GTK+ functions have parameters with GLib or Pango types; it's
in fact not possible to write an interesting GTK+ program without
GLib calls, such as g_signal_connect() and g_free(). Now, we could
document that the way to compile a GTK+ program involves

 pkg-config --libs gtk+-2.0 pango atk glib-2.0

but that is just making things harder for users for no good reason.
It's much better if pkg-config --libs gtk+-2.0 includes everything
that the user needs.

Regards,
						Owen