Re: -Wl,--as-needed considered possibly harmful
> due to the recent dpkg-shlibdeps changes, people have started adding
> -Wl,--as-needed into their LDFLAGS.
>
> THIS IS NOT A GOOD IDEA.
>
> You are essentially telling gcc to pass an option to the linker without
> understanding what it does, and, more specifically, an option that tells
> the linker to second-guess the gcc compiler driver. This can introduce
> really interesting and subtle bugs that will be difficult to find.
To first order, the only scenario I am aware of in which it can cause
problems is if someone uses a global variable with a C++ constructor
in a shared library, that constructor does critical work for the
application the library is linked into, and the application does not
reference any symbols whatsoever from the shared library. This is not
impossible, but it is so unlikely IMO that the possibliity can be
neglected.
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?
> 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.
There are a *lot* of broken scripts. Would you like to mass-file bugs
on every package that contains a binary that links to libnsl? (this
iscommon, thanks to a buggy example in the autoconf manual, but
completely unnecessary under glibc for anything other than a small
handful of NIS-related programs, which probably have their own copies
of that code anyway) How about programs that link to libm, but every
symbol they use from libm happens to have been replaced by inline
code? (I have seen this happen in real life.) Libraries that are
linked against libpthread as a defensive measure for actual use of
threads by their users, but only need the stubs in libc for that?
(Can causes severe performance hits for single-threaded users of that
library.)
zw
Reply to: