[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DSO linking changes for wheezy



On Sun, Nov 14, 2010 at 01:19:08PM +0100, Julien Cristau wrote:
> On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote:
> 
> > For wheezy I'm planning to change the linking behaviour for DSOs
> > (turning on --as-needed and --no-copy-dt-needed-entries. The
> > rationale is summarized in
> > http://wiki.debian.org/ToolChain/DSOLinking. I would like to know
> > about issues with these changes on some of the Debian ports, and if
> > we need to disable one of these changes on some port.
> > 
> --no-add-needed sounds like it'll cause a *lot* of build failures for no
> particular gain.  I don't think it's a good idea.

This change will definitely cause a lot of link failures; having some
concrete numbers to determine how many would be quite useful here, e.g.
from an archive-wide rebuild.

Example failure case:

#593876 libboost-filesystem-dev: Undeclared indirect dependency of boost_filesystem on boost_system causes link failure

While --no-copy-dt-needed-entries does "fix" programs depending upon
indirect linkage, this is something we've been relying on for over a
decade and has worked quite well in practice.  While strict correctness
is nice to have, and I've already fixed my programs to work with strict
linking, I'm not entirely sure why indirect linking is that bad in
practice.

Note that in the above Boost example, you get caught out just due to
some inline functions in headers resulting an a completely unexpected
additional dependency, so the need for linking is there, but would have
otherwise been happily satisfied indirectly.  Also, it means that the
user of a library needs to be intimately aware of its internals which
is not good.  If the Boost filesystem library changes how it works but
without changing its public interface, I could be screwed again in six
months time.  This is partly the fault of Boost for exposing its
internals in its headers, but disallowing indirect linking make it
worse.

Overall, it could be for the best, but it will be painful initially.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature


Reply to: