Chow Loong Jin <hyper...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/87vcnvmhx6....@windlord.stanford.edu
