On 23 Jul 2010 at 13:56, Jim Bosch wrote: > Given that many people (including myself) have pickled Boost.Python > objects inside dicts many times before without issue, it might be tricky > to make a contained example that reproduces it this problem. And I'm > less motivated now because I can just skip pickling the object in this > case and move on with my life... > > But if anyone has any new ideas on where to look, it does seem like > mysterious behavior that would be nice to track down.
What can happen is that some python loadable modules have implemented explicit symbol hiding while others have not - or worse, some parts of a python loadable module have a properly shown ABI while other parts don't. This can cause symbols to get overridden in a way you wouldn't think. For example, Boost.Python does hide unneccessary parts of its ABI because it reuses its MSVC DLL symbol export machinery to do so (I contributed the patch myself). If however another library used BPL to wrap itself but did NOT use said symbol export machinery then one could end up in an inconsistent state depending on basically which way the wind is blowing on the day. Because of these complexities, some - actually many - still feel that everything should be made public like it used to be then "it works". And indeed this is correct. However, it also takes the runtime dynamic linker - which is an O(N^2) beasty - much longer to load your executable which for OpenOffice and KDE meant a 60 sec load time back in the day. And there is much to be said for the notion that a reusable shared object should be responsible enough not to pollute the process namespace willy nilly, plus of course there are security issues with the more information you expose about the inner layout of your binaries. Basically the ELF shared object format is broken and needs fixing so it looks much more like PE's DLL format. But fixing this is years away, if ever, so for now we make do ... HTH, Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig