Re: Summary of C++ symbols experience
Chow Loong Jin <hyperair@debian.org> writes:
> On 29/01/2012 08:19, Russ Allbery wrote:
>> Oh, hey, indeed. Right, I didn't realize the implication of what you
>> were saying.
>> So... what if dpkg-gensymbols implicitly marked all weak symbols as
>> optional and didn't care if they disappeared? Would that make sense to
>> do? pkgkde-gensymbols could also mark all weak symbols as optional
>> automatically in the interim.
> No, that would break libraries that do use __attribute__((weak)). I
> think (e)glibc, at least, uses it, in this most horrible way that I have
> never been able to understand. (I tried to modify the open() call once
> to hack around a bitflag conflict between an old Ubuntu OpenVZ client
> and a RHEL host, but never managed to find the correct one to
> modify.. ¬_¬")
So I guess what I want is a non-default flag to pkgkde-gensymbols or to
dpkg-gensymbols that says "add (optional=weak) tags to every weak symbol
because I'm C++ and know that the only use of weak is inlined functions."
Hm. I'd have to see in practice since there's too much stuff to
comprehensively check all of it without writing code that would amount to
the changes I think should be made, but I think that and subst takes care
of all the symbols issues I'm seeing except for this stuff:
(arch=!amd64 !ia64 !kfreebsd-amd64 !s390x)_ZTch0_v0_n124_NK8opensaml7saml2md22OrganizationURLBuilder11buildObjectEPKtS3_S3_PKN10xmltooling5QNameE@Base 2.4.3
(arch=amd64 ia64 kfreebsd-amd64 s390x)_ZTch0_v0_n248_NK8opensaml7saml2md22OrganizationURLBuilder11buildObjectEPKtS3_S3_PKN10xmltooling5QNameE@Base 2.4.3
(There were hundreds of these.) Note that the only difference is the
"n124" vs. "n248", which appears to be directly related to whether the
system is 64-bit, and both symbols demangle to the same thing:
covariant return thunk to opensaml::saml2md::OrganizationURLBuilder::buildObject(unsigned short const*, unsigned short const*, unsigned short const*, xmltooling::QName const*) const
Presumably this is another case where pkgkde-symbolshelper should really
demangle the symbol and use the symbolic version so that it will match on
both platforms and not create the above fragility when we add a new
architecture.
I see a bunch of bugs to file against pkg-kde-tools in my future. :)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: