Re: linker related changes for wheezy
Hi,
On Sun, Feb 27, 2011 at 1:00 PM, Matthias Klose <doko@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
Reply to: