FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 12-09-2007, 11:17 PM
Steve Langasek
 
Default -Wl,--as-needed considered possibly harmful

On Sun, Dec 09, 2007 at 03:47:52PM -0800, Steve Langasek wrote:
> > However, not all applications uses those symbols in their current code, so
> > they do not need to be linked against speex themselves.

> And therefore, the scripts generating dependency information for dynamically
> linking to libshout should *not* list libspeex or libtheora, and
> consequently there's no need for -Wl,--as-needed. (When statically linking,
> -Wl,--as-needed is also irrelevant, because unused symbols from static libs
> are already discarded.)

> > Of course, correct dependencies will be pulled when requesting libshout.

> No, currently the dependencies pulled in are overbroad. Please fix
> /usr/lib/pkgconfig/shout.pc to list the dependent libraries in
> "Requires.private", not in "Requires".

... also, -Wl,--as-needed is *not* a complete solution for the problems
caused by generating extra -l arguments. Every -lfoo option passed to the
linker requires the corresponding -dev package to be installed at build
time; while it is a bug if the -dev packages don't declare their
dependencies, the impact of such bugs (which do happen fairly often) would
be limited to static linking if appropriately-constructed .pc files were
available.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-10-2007, 02:35 AM
Felipe Sateler
 
Default -Wl,--as-needed considered possibly harmful

Steve Langasek wrote:

> ... also, -Wl,--as-needed is *not* a complete solution for the problems
> caused by generating extra -l arguments. Every -lfoo option passed to the
> linker requires the corresponding -dev package to be installed at build
> time; while it is a bug if the -dev packages don't declare their
> dependencies, the impact of such bugs (which do happen fairly often) would
> be limited to static linking if appropriately-constructed .pc files were
> available.

Note that pkgconfig is not the only problem here. Some extra links arise
from the fact that several utilities or plugins for an application are
built with the same "environment" (ie: the same flags), and not all of them
require all the linked libraries. Of course, one could argue that fixing
the build script is the way to go, but sometimes it is not trivial to do
that (badly crafted or unmaintained build scripts tend to be quite ugly).


--

Felipe Sateler


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-10-2007, 12:17 PM
Loc Minier
 
Default -Wl,--as-needed considered possibly harmful

On Sun, Dec 09, 2007, Simon Richter wrote:
> If there are broken scripts adding too many libraries then it is time to
> fix those scripts, not employ an evil hack that makes the symptoms go away.

We met actual cases were --as-needed breaks things; however, for pure C
program, I think combining it with "-z defs" should be safe:
LDFLAGS += -Wl,-z,defs -Wl,--as-needed

Sadly, there are many cases where "-z defs" will actually fail the
build, for example when creating Python bindings: these may not be
linked to libpython or to python as they might be loaded from either
one, and you don't want to load the other one (if you run within
python, you don't want to load libpython and vice-versa). In such
cases, -z defs will fail the build because of missing link flags for
the Python symbols.

I heartily agree with other people that fixing the build rules to not
add superfluous link flags is the best thing to do, but this ain't easy
in many cases, and --as-needed might allow us to benefit from shorter
Depends immediately. If fixing the build is too hard and your build
passes with -z defs, then you are probably safe with --as-needed.


NB: -z defs is the same as --no-undefined.
--
Loc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-10-2007, 12:49 PM
Loc Minier
 
Default -Wl,--as-needed considered possibly harmful

On Sun, Dec 09, 2007, Zack Weinberg wrote:
> I have in the past argued for --as-needed to be made the default in
> upstream binutils; that's how safe I think it is. (Upstream
> maintainers, conscious of the above and other (isomorphic) corner
> cases, wanted a distribution to try it on a large scale first. Thus I
> am very happy to see Debian experimenting with it.)
>
> I'm curious what prompted your message. Did a program you use
> actually break? What was the failure mode?

When this was added to pkg-gnome at large, we were hit by at least
toolchain issues on some arches (was it hppa?) -- now fixed -- and also
got some borken packages. I think gnome-panel / gnome-applets and
gedit were the two packages that were hit when we added --as-needed.

I think in both cases it was something like the main binary being
linked to many utility libraries (because it was easy to link it to
everything which configure found), and then the plugin calling directly
into these libs, but not being linked to them. If the main binary
didn't actually use the libs, these were stripped out, and then the
dlopening of the plugins would fail.
These were really issues in the build process, issues which would
have been caught with -z defs before --as-needed (which is why I'm
advocating usage of -z defs before --as-needed), but slipped silently
in the end package and actually hit users.

I don't think there's an insanely strong incentive to make --as-needed
the default or to not make it; distros such as Debian and Gentoo are
using it wildly at the moment; it just can point out some surprize
bugs in my experience.

HTH,
--
Loc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-10-2007, 01:02 PM
Sune Vuorela
 
Default -Wl,--as-needed considered possibly harmful

On 2007-12-10, Loc Minier <lool@dooz.org> wrote:
> I think in both cases it was something like the main binary being
> linked to many utility libraries (because it was easy to link it to
> everything which configure found), and then the plugin calling directly
> into these libs, but not being linked to them. If the main binary
> didn't actually use the libs, these were stripped out, and then the
> dlopening of the plugins would fail.
> These were really issues in the build process, issues which would
> have been caught with -z defs before --as-needed (which is why I'm
> advocating usage of -z defs before --as-needed), but slipped silently
> in the end package and actually hit users.

Isn't the new dpkg-shlipdeps warning about symbols it can't find ?

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-10-2007, 01:20 PM
Loc Minier
 
Default -Wl,--as-needed considered possibly harmful

On Mon, Dec 10, 2007, Sune Vuorela wrote:
> Isn't the new dpkg-shlipdeps warning about symbols it can't find ?

Indeed; I was telling a story from the dark ages where .debs were
crafted with silex in your bare hands.

That said, -z defs is a good idea to check all intermediate objects and
to make the build actually fail on the first incorrect intermediate
object (dpkg-shlibdeps will only tell you at the end of the build and
only tell you about the installed final objects with missing NEEDED).

--
Loc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-10-2007, 03:45 PM
Josselin Mouette
 
Default -Wl,--as-needed considered possibly harmful

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

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
 
Old 12-10-2007, 04:29 PM
Raphael Hertzog
 
Default -Wl,--as-needed considered possibly harmful

On Mon, 10 Dec 2007, Sune Vuorela wrote:
> On 2007-12-10, Loc Minier <lool@dooz.org> wrote:
> > I think in both cases it was something like the main binary being
> > linked to many utility libraries (because it was easy to link it to
> > everything which configure found), and then the plugin calling directly
> > into these libs, but not being linked to them. If the main binary
> > didn't actually use the libs, these were stripped out, and then the
> > dlopening of the plugins would fail.
> > These were really issues in the build process, issues which would
> > have been caught with -z defs before --as-needed (which is why I'm
> > advocating usage of -z defs before --as-needed), but slipped silently
> > in the end package and actually hit users.
>
> Isn't the new dpkg-shlipdeps warning about symbols it can't find ?

Only if the library has a SONAME. This is intended so that
perl/python/apache modules do not generate bad warnings: they rely on the
binary dlopening them to provide the symbols (and it's okay that way).

So the problem might still be missed on some plugins without SONAME.

Cheers,
--
Raphal Hertzog

Le best-seller franais mis jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-10-2007, 05:24 PM
Neil Williams
 
Default -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
-lglib-2.0

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
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 
Old 12-10-2007, 05:47 PM
Michael Poole
 
Default -Wl,--as-needed considered possibly harmful

Steve Langasek writes:

> On Sun, Dec 09, 2007 at 07:23:00PM +0100, Josselin Mouette wrote:
>
>> Le dimanche 09 dcembre 2007 19:11 +0100, Bernhard R. Link a crit :
>> > Just curing the symptoms instead of the problems will not help to get
>> > there any sooner.
>
>> What if there is no problem?
>
>> For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
>> -lglib-2.0 and -lm. And this is perfectly intentional.
>
> Just because it's intentional doesn't mean it isn't absurd and wrong.

What happens for a user who (however absurd or insane he might be to
try this with gtk+) tries to link his application statically?

Perhaps the "absurd and wrong" part is that pkg-config does not
provide a way to distinguish between use cases, and that the name for
the current behavior should also be --static-libs rather than --libs,
but there is a good reason to provide the transitive closure of
dependencies for a package *somewhere* in pkg-config.

Michael Poole
 

Thread Tools




All times are GMT. The time now is 11:56 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org