> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
