[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: -Wl,--as-needed considered possibly harmful

Josselin Mouette wrote:
> Le dimanche 09 décembre 2007 à 15:44 -0800, Steve Langasek a écrit :
>>> For example, pkg-config --libs gtk+-x11-2.0 will return, among others,

I don't have a problem with libglib2.0-0 in gtk+2.0.pc - it may well be
correct to have that one in the pkgconfig because gtk headers define
variables in terms of Glib typedefs. (I have to do the same with libqof1).

The actual string is:
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
-lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl

As I see it, there are a few problems here, one of which is in libglib2.0:

1. Glib: gmodule2.0 (and it's variants) shouldn't export -ldl. This is
minor because it's a libc6 lib anyway so it doesn't cause an extra
dependency but it will be the only "unwanted" link in the next version
of libqof1 now that I've fixed the others.

2. Gtk+2.0 really shouldn't export gmodule. Even if there is a reason
for lglib2.0, there is no reason for -lgmodule. It is trivial to omit
this linkage from the gtk+2.0.pc file.

3. Ditto for gobject although I might be wrong on that one.

4. Gtk+2: There is no need, as I see it, for atk, m, pangocairo, pango
or cairo to be Requires: in gtk+2.0.pc - these should be
Requires.private: instead.

This is the single largest cause of unwanted linking in GPE.

Sadly, it isn't possible to get lintian to check for these inter-package
problems but the basic check, IMHO, would be to check the headers of the
-dev package against the headers of the package being considered for
Requires: If none match, it should be Requires.private:

It should be possible to automate that in perl or python - gather the
declarations of your package into a hash, read in the declarations of
the package being considered for Requires:. No matches ->
Requires.private or omit altogether.

The problem is how many packages already have this assumption built-in
and will FTBFS when gtk+2.0.pc changes to drop the extra libraries.
Theoretically, other packages should have done things properly and
specified their -dev packages in full but I think that isn't going to be
the reality.

>>> -lglib-2.0 and -lm. And this is perfectly intentional.
>> Just because it's intentional doesn't mean it isn't absurd and wrong.
> It may be absurd, but I don’t think it is wrong.
>> No, what can be done is to fix upstream's broken declaration that 'you can
>> assume glib functions are available when doing "#include <gtk/gtk.h>"'.  It
>> doesn't follow that just because this works in practice, it should be a
>> supported usage.
> When many of the types used by GTK+ are those provided by GLib, it
> sounds wrong to ask developers to include the GLib headers to have these
> types available.

Maybe so, but it doesn't excuse the rest.


Neil Williams

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: