Re: Bug#700737: binutils-gold: produces different symbols for webkit
Am 17.02.2013 11:27, schrieb Jonathan Nieder:
> tags 700737 + moreinfo
> Hi Michael,
> Michael Gilbert wrote:
>> - (optional|c++)"WebCore::TextIterator::getLocationAndLengthFromRange(WebCore::Element*, WebCore::Range const*, unsigned int&, unsigned int&)@Base" 1.7.4
>> +#MISSING: 1.8.1-3.3# (optional|c++)"WebCore::TextIterator::getLocationAndLengthFromRange(WebCore::Element*, WebCore::Range const*, unsigned int&, unsigned int&)@Base" 1.7.4
> From the dpkg-gensymbols(1) manpage:
> A symbol marked as optional can disappear from the
> library at any time and that will never cause
> dpkg-gensymbols to fail.
>> @@ -213,6 +213,7 @@
>> _NPN_SetException@Base 1.3.10
>> _NPN_SetProperty@Base 1.3.10
>> _NPN_UTF8FromIdentifier@Base 1.3.10
>> + _ZdlPv@Base 1.8.1-3.3
> c++filt tells me this is operator delete(void*).
> So presumably an entry
> (optional|c++)"operator delete(void*)"
> would suppress the build failure. Can you say a little more about
> whether this is a gold bug? Do binaries built against versions of
> libwebkit built with gold rely on this symbol and fail when run
> against libwebkit built with ld.bfd?
> In C++, different lists of exported symbols based on the phase of moon
> are completely normal, for example when template instantiation is
> involved. So more details would be welcome.
I think that dpkg-gensymbols is misleading in that it treats all symbols
exported as the same, not differentiating where they come from. Yes, you do have
the option to mark a symbol as optional, however marking a symbol as coming from
another library (libstdc++, Webkit:Core) would help too, but would require some
work by the package maintainer too. Whether a template operator or another
template from another library ends up as an exported symbol depends on the
toolchain (different compiler/linker, different version, different optimization
level), and that should not be encoded in the symbols files.