The attached patch adds a missing -lm linking to the
executables makefile allowing to use --as-needed
LDFLAG while building the package.
Diego "Flameeyes" Pettenò
Logged In: YES
Roger, can you evaluate this? If this should be done, I'd
like to do it for -rc2.
Logged In: YES
The binaries are already linked to libm indirectly through
libgutenprint. Why do they need direct linkage?
Why are you using --as-needed? This option /removes/
libraries from the link line after it is specified, so
should be completely unaffected by adding -lm. In addition,
for these binaries --as-needed should have no effect,
because we are not linking any unneeded libraries (as far as
I can tell).
I'm not against the patch as such, I would just prefer to
understand its purpose before adding it.
Logged In: YES
Well seems like the linking of -lm in libgutenprint is
discarded by --as-needed at least on my system, so the
binaries losts its linkage.
While on gutenprint it does not really do that much of a
change, I'm trying to fix the cases where it does create
failures using it generally for the system. While not
using gnome, the number of failures I've seen is really
low, so I've sent a few patches when it was the case.
Does --as-needed fail for all the other binaries linked with
libgutenprint?, or just these two?
This looks like a bug in --as-needed in binutils, so this is
what really needs fixing. The patch as it stands will break
OS X (libm is part of System.dylib), so I would need to make
some changes in configure to conditionally substitute it.
If Robert thinks that's worth doing, I'll do that.
What is the purpose of --as-needed? How critical is the
Okay I improved the patch now over rc2.
The attached patch changes the check for libm in the
configure to provide a MATH_LIB variable, and then add it
to the linking of the binaries which fails.
This works for OS X, too, as 10.3+ provides a link between
libm.dylib to System.dylib, and for the previous versions
the check will fail so the problem is avoided.
For an explaination of --as-needed, I've wrote a simple
guide on Gentoo Documentation:
Roger, is this something we should do anything with? Should
we keep it around and do it after 5.0, or close it?
This patch looks like it's working around a binutils bug on
Gentoo, when using a known buggy linker option.
libgutenprint is linked with -lm, so all binaries linked
with libgutenprint will link indirectly with libm.
The --as-needed option is for some reason removing libm
from DT_NEEDED, which is totally broken.
I don't think we should be applying patches to work around
breakage in a distribution, particularly when broken linker
options are being used, so I think we should close the bug.
The submitter has not provided any information about
what /exactly/ is breaking. We have no specific details
about what the --as-needed option changed, presumably the
dynamic section in libgutenprint and/or the binaries. We
need to understand what changed, (and why) before making
We don't even know which version of binutils was used.
This is not a _binutils_ bug to work around, is a
gimp-print bug. The link I provided (
http://www.gentoo.org/proj/en/qa/asneeded.xml ) contains
all the information about the flag and how it works. The
binutils version is everything starting from 2.16.91.x, if
it was a binutils bug, it wouldn't be there in 2.16.93
that didn't die on any package up to now.
What you are doing is simply linking libm on gutenprint
_libraries_ that are *not* using functions from it, to
avoid linking the two binaries using it, but --as-needed
discards -lm linking _as it should_, *it's not a bug*, as
you would know if you read that guide above (that once
again has _all_ the information you need to know and even
The guide itself contains the following:
Warning: At the time of writing, there are many packages
failing in funny ways because of --as-needed as they weren't
designed to be used with it. While there shouldn't be (note
the conditional) problems such as crashes, this flag is not
considered safe for production use and not supported in any
way by Gentoo.
What is the impact of *not* doing this? What would be the
impact if we were to hold off doing it for a while?
The warning there is to avoid "ricers" (users that adds
all the possible flags in the world and then file bugs
without caring about whatever they did before, we're
plenty of them :)). In general, there is no problem with
the patch being used without --as-needed, actually it
changes nothing but that's not the point.
If you put this on hold, I suppose the worse that can
happen is that we'll have to continue patching gutenprint
and running automake on it for every user :) And so might
other distributions, too. (AltLinux iirc is working on
The page you provided a link to does not provide the
information I need.
I want to know, *specifically*, what is happening for
gutenprint. I want a dump of the ELF private headers
(objdump -p) for libgutenprint.so and also for both working
and broken binaries both with and without this option, so
that we can see *exactly* what is going on. That is, I
want the information for:
rastertogutenprint and/or genppd
and then any other program e.g. canon or epson
Your patch makes the CUPS binaries link with libm even when
it is not required. The dependency is already fully
described in DT_NEEDED:
$ objdump -p /usr/lib/libgutenprint.so.2 | grep NEEDED
If I link against this, I will always have an indirect libm
dependency. If --as-needed breaks this, --as-needed is
broken. The binary in question does not use any libm
$ nm -D /usr/lib/cups/filter/rastertogutenprint.5.0 |
grep 'U '
$ nm -D /usr/sbin/cups-genppd.5.0 | grep 'U '
Please correct me if I am wrong, but I would like to
understand the specifics.
Okay, you probably didn't understand what --as-needded is
designed for :) The dropped NEEDED line for libm.so is
supposed to happen, because libgutenprint.so.2 does not
import symbols from that. It's not broken, the code that
relies on -lm being linked from that library is broken,
rather. This is how linking is supposed to be in the first
At least here on my system, both binaries requires the
pow() function, that is in libm, and pow() is -probably
not a coincidence- the function that's tested with
What you're doing right now is forcing an unneeded
dependency over libm.so in libgutenprint.so.2, for the
only sake of those two files (or maybe some other program
that uses functions from libm but does not consider
important explicitly link against libm (which is a broken
Okay, just noticed now a thing: rc2 forced the dependency
although not using functions from libm; rc3 seems to use
functions from there and libm is not discarded anymore, so
it is somehow fixed, although the patch would be on the
side of "play it safe".
If you are still interested in the specifics, libdl.so is
still discarded because it's not used.
rc2 most certainly used the pow() function. The color code
has used it since time immemorial.
Forcing everything that links against libgutenprint to
explicitly link against libm seems to me to be the wrong
thing to do. It means that if we ever decide to import
something else into gutenprint that anyone who links against
it has to change their link line.
I don't know if it's the same problem, but linking against
libreadline is a real headache; it has dependencies on
libncurses, libtermcap, or the like. We had to put some
really ugly workaround code in our configure.ac to figure
out what libreadline's dependencies are. If this patch
forces other projects to do the same for us, I cannot see
how it can be right.
Please answer Roger's questions specifically.
Well not in that library at least for what the linker
could say. I must say it might be that for some reason
that code wasn't enable for me, not sure.
And no, --as-needed is not meant to create the same hell
as older libreadline dependency hell, but to alleviate it.
Basically it would force libreadline to _not_ force other
software to figure out what it was built with, by linking
the stuff it needs itself.
Right now I don't have time for three rebuilds of
gutenprint, if you want I can try to provide it tomorrow,
but as I said, now it's no more a concern as rc3 fixed the
thing already (although I have no clue how, tbh).
> If you are still interested in the specifics, libdl.so
> is still discarded because it's not used.
That's not specific enough. I'd like actual details of
what really happened and why, rather than vague
Note that libdl is most certainly used. If it's removed,
it will break the module loader. This depends on the
options given to configure, but if libdl was linked in, it
is *required* for libgutenprint to function, because
without the modules, the printer family drivers can't be
I would still like the information from the builds. Note
that you only need two builds: one with -Wl,--as-needed,
and one without.
This particular code hasn't been changed by us in the last
year, and probably not in the last three since it is
stable. I would suspect that updates to the Gentoo
binutils are a more likely candidate for the breakage. In
Debian, we did consider using --as-needed to reduce
unneeded library dependencies, but it is still buggy and
does cause breakage. The best long-term solution is to fix
the tools and packages linking in unnecessary libraries,
rather than papering over the problem with an ugly ld hack.
Also note that --as-needed is not a universal panacea. It
can only detect direct dependencies. It would miss things
like _init/_fini or __attribute__(constructor/destructor)
functions. We don't use those, but it could break C++
static initialisers depending upon how the code is linked.
There are also other cases where it will cause breakage.
Sometimes libraries are required, even when there are no
In our case, the libm and libdl dependencies should never
be removed, because libgutenprint uses them directly.
$ nm -D /usr/lib/libgutenprint.so.2 | grep pow
$ nm -D /usr/lib/libgutenprint.so.2 | grep dl
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.