Hi, On Sun, Feb 27, 2011 at 1:00 PM, Matthias Klose <d...@debian.org> wrote: [...] > The latter change is described in [1] (section [2]). To summarize: If a > library > symbol is directly used by an object without explicitly linking this library, > the link step now fails. The fix is to pass the library explictly to the > linker. Rationale for this change: > > - Correctness. Symbols should not be resolved unintentionally. > > - Robustness. If a library drops a dependency on another library > with the involved symbol, then the application still using this > symbol will fail to build. > > - Buildability with the gold linker. Gold defaults to > --no-copy-dt-needed-entries. Using gold as the default linker > is not a goal for wheezy, but buildability of the archive with > gold is required as a prerequisite. [...]
Those are valid points, of course, but many Boost projects will fail to build now and I see no good solution[1][2][3]. Some libraries like libboost-filesystem and libboost-asio implicitly depend on libboost-system or libboost-thread or some other Boost library because they refer to their symbols in inlined functions and methods. This is a technical requirement mostly related to C++ templates (though C libraries could be affected too if they use inlined code). The problem with simply "adding the missing libraries" to each project's build system is that those dependencies aren't documented anywhere. The mantainers would have to add them manually in each project's build scripts. The dependencies might change in the future, too, and in that case the package will fail to build again. Roger Leigh proposed pkg-config integration in Boost[4] but got no feedback. That would be a way out of this problem, but I suspect upstream is not really interested. It could be argued that --no-copy-dt-needed-entries is C-centric since it ignores the problems faced by libraries that expose C++ templates. In situations like this, what can package maintainers do? Would adding -Wl,--copy-dt-needed-entries to the build script be acceptable and would gold support that flag too? Should the bugs be assigned to the libraries instead (Boost and others)? There's no way this can be considered a bug in the packages that use such libraries, it makes no sense. Thanks, [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248674 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602959 [3]: http://lists.debian.org/debian-devel/2010/12/msg00055.html [4]: https://svn.boost.org/trac/boost/ticket/1094 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikxekrxx5td9fctfp64r_gye-vhqyoz4vo...@mail.gmail.com
