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

[Dom Lachowicz]

--- Owen Taylor <otaylor at redhat.com> wrote:
> 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.

I agree with Owen that hiding internal dependencies
from the linker is a good idea wherever possible.
However, what we have in practice now is an odd
mixture of hiding internal dependencies and exposing
them.

I had a discussion with Owen in B.G.O. about this
problem last week. Owen - apologies in advance for
bringing it up again here. I just want to get a clear
idea of exactly what role 'pkg-config --libs' serves
and what my role as both a consumer + producer of .pc
files is.

Given:
$prompt> pkg-config --libs pangoft2
-lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0
-ldl -lglib-2.0

Given:
$prompt> pkg-config --cflags pangoft2
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include

This exposes a dependency on freetype2 and fontconfig,
whereas '--libs' does not mirror this dependency. 

I argue that dependencies such as "gmodule-2.0" and
"dl" are not exposed via pangoft2.h's API, nor via
anything that pangoft2 #includes. 

Since pangoft2 exposes FT_Bitmaps and FcPatterns to
its API consumer, should '--libs pangoft2' return
them? Or is the onus on the API consumer to add
"-lfreetype2 -lfontconfig" to the link line? 

If the latter is the case, what is the value in using
pkg-config beyond some it being a library
version-control mechanism? If the latter is the case,
what makes "exposing dependencies that are part of
your API" in GTK+ different (as Owen argues)? Remember
that GTK+ exposes "-lpango -lpangoxft -lpangox11
-lglib -lgobject -lgdk ..." where all you really
probably care about is "-lgtk+-2.0". Further, things
like pangoxft2 and pangox11 aren't exposed by gtk*.h
but are solely internal dependencies.

I'm musing that we need is a general-purpose solution
for this inside of pkg-config, or at least some
healthy house-cleaning in our respective libraries and
applications. I'd like to propose these pkg-config
semantics:

1) A --libs option that gives us an absolute minimum
set of exposed dependencies. Here, an "exposed
dependency" is a dependency on any library that your
API exports, recursively. If you expose a Freetype API
dependency, you -lfreetype plus anything that
freetype.h exposes.

2) An --all-libs option that gives us the complete set
of dependencies, recursively. Here you list every
library that you link against, plus every library that
they link against, ad nauseum. This is useful for
things like pre-linking on Mac OSX (why Owen and I had
our original discussion).

I'd like to at least ask for #1 to happen, and then do
the requisite house-cleaning to make it happen. If #2
doesn't happen, so be it. But I'd like to clean up
what I see as glaring inconsistencies in 'pkg-config
--libs' usage.

Please feel free to tear this to shreds if need be.
I'm just interested in exactly what the rules here are
so that I can go about business as usual.

Best regards, and apologies to Owen again,
Dom

=====
I think the problem with the Democratic Party in general is that they've been so afraid to lose they're willing to say whatever it takes to win. And once you're willing to say whatever it takes to win, you lose. - Howard Dean

http://www.deanforamerica.com/

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools