https://bugs.freedesktop.org/show_bug.cgi?id=45696
Stephan Bergmann <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED AssignedTo|[email protected] |[email protected] |desktop.org | CC| |[email protected] --- Comment #3 from Stephan Bergmann <[email protected]> 2012-02-06 06:18:05 PST --- To clarify: The problem (abort of ".../python -c 'import uno'") should only happen with the LibO packages as available from <http://www.libreoffice.org/download/>. It should not happen with installation sets specificially built for those platforms. <http://cgit.freedesktop.org/libreoffice/core/commit/?id=0b1be1ce0e0ac7b34c4b73d53f4bf32ec5df7290> "Reintroduce pyuno.so wrapper around libpyuno.so" (on master towards LO 3.6) should fix the problem. It re-introduces some dirty platform-specifc makefile code; once it is known to work fine across the various platforms on LO master I will take care to get it cherry-picked into -3-5. The problem is as follows: <cgit.freedesktop.org/libreoffice/core/commit/?id=a09ce46818fd4d5e08b3af9a478501cd8ef5b4fe> "Port PyUno to support Python 3" erroneously cleaned away the pyuno.so wrapper around libpyuno.so (it turned the former into a symlink to the latter). The wrapper is needed to make sure libpyuno.so (which in turn links against many of the URE libs, incl. cppuhelper) is dlopen'ed RTLD_GLOBAL (while Python apparently dlopen's its modules RTLD_LOCAL). At least with pre 4.5 GCC versions where C++ exception RTTI data is compared for equality by only comparing pointers to strings (instead of the content of the strings), this causes an InvalidRegistryException thrown from boostrap.uno.so (dlopen'ed RTLD_GLOBAL via sal) to erroneously not be caught by cppuhelper (loaded as a consequence of loading libpyuno.so aka pyuno.so as RTLD_LOCAL), as the two libs bind to different instances of the InvalidRegistryException RTTI symbols. The problem of loading libpyuno.so as RTLD_LOCAL gets hidden with recent GCC runtimes that actually compare the content of RTTI strings. However, the packages available from <http://www.libreoffice.org/download/> are built on a rather old baseline system and without --without-system-stdlibs, so they include old versions of libstdc++.so.6 and libgcc_s.so.1 that still compare RTTI pointers only (and the programs in the LibO installation then use those versions, instead of the ones provided by the system). Reportedly, the GCC behavior changed with GCC 4.5 (and already with GCC 4.4.1-2 for RHEL/Fedora). That is, only LibO installations that use older libstdc++.so.6/libgcc_s.so.1 than that (either from the system or included in the LibO installation) are affected. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
