On 16.11.2010 01:24, Roger Leigh wrote:
On Mon, Nov 15, 2010 at 11:02:57PM +0100, Matthias Klose wrote:
On 14.11.2010 16:06, Roger Leigh wrote:
While I understand the rationale for --no-copy-dt-needed-entries for
preventing encapsulation violations via indirect linking, I don't agree
with the use of --as-needed *at all*. If a library has been explicitly
linked in, it shouldn't be removed. This is an issue for fixing in
individual packages, not in the toolchain.
I can understand on using it on a per-package basis, but not in the
actual toolchain defaults. The compiler and linker *should not be
second-guessing the user*. This can break perfectly legitimate code
making use of ELF constructors and other features which won't be
picked out just by looking at symbol usage.
People have been claiming that constructors or init section are a
possible problem. I have yet to see an example where it breaks.
It's not a very widely used feature. I'm sure it's trivial to make
such a test case. Portable software tends not to make use of ELF-
specific features like this, but that's not an excuse for breaking
perfectly legitimate code.
But whether or not there are real life examples, --as-needed is
*fundamentally wrong*. It's deliberately *not doing what the user
requested*, and to make that misfeature the system-wide default
would be entirely inappropriate. If a package wishes to make use
of such a feature after understanding the implications, then they
are free to do so. But to make it the default--I don't think that's
a technically sound decision.
maybe, and fix it in N - ~100 packages? Or fix the ~100 packages? The
point of injection is for discussion. I would prefer having this set in
dpkg-buildflags, and then disabled by these ~100 packages. Note that
this is probably the same like modifying the N - ~100 packages, as almost
no package respects dpkg-buildflags yet.
What's the actual problem --as-needed is trying to solve?
why did I explain it in the wiki?
The answer is mainly unwanted libraries being linked in as a result
of using pkg-config (and various other -config variants), though there
are other, lesser, culprits. The pkg-config .pc files for gtk, gnome
and other libraries add in many libraries, most of which aren't
typically needed.
The solution: fix the .pc files!
and add more .pc files? Definitely not. I didn't see that many packages where
different binaries/libaries were linked with a different set of libraries.
Usually this is already introduced by upstreams.
Using --as-needed is merely papering over the actual root problem.
It "fixes" the symptoms, but it's not addressing the actual cause.
The number of packages providing broken .pc files is not large, and
the number breaking due to relying on this brokenness is likely
just as small.
Other libraries being linked unnecessarily can be removed on a
per-package basis. lintian is warning about this, so most developers
should be aware of the problem.
Damaging our toolchain to work around buggy build scripts is wrong; we
should just fix the scripts!
again, this is not a script/pkgconfig problem only.
Matthias
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ce1d23f.7000...@debian.org
