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.
Matthias
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ce1ae11.2010...@debian.org
