There is a similar crash that occurs when using a wx.Printer.
Anyway, I've spent considerable time investigating these and found that the crash is because GTK performs some dlsym() calls to lookup symbol names and fails in going so because its symbols were loaded in the local namespace, not the global namespace (ie, RTLD_LOCAL vs RTLD_GLOBAL). I've discussed this with the GTK devs and basically, GTK expects its symbols to be loaded globally.
Thus, I have a solution that I would like to propose for discussion:
# Load the package namespace with the core classes and such
+import dl, sys
+flags = sys.getdlopenflags()
+sys.setdlopenflags(flags|dl.RTLD_GLOBAL)
from wx._core import *
+sys.setdlopenflags(flags)
del wx
if 'wxMSW' in PlatformInfo:
···
===
Basically, this would change the dlopen flags before importing the core module to RTLD_GLOBAL and then change them back afterwards. That way, the core module and its dependencies (to include GTK) are loaded into the global namespace.
Comments on this proposal?
It needs more work but I wanted to get feedback before finalizing a patch. (ie, it probably only needs to be done on when we're using a GTK+3 backend, needs to check whether the dl module is available, etc.)
Okay, here's an updated version of the patch. Unfortunately, it isn't possible to check the backend (and only change the dlopen flags if on GTK+3) because the backend isn't known until _core.so is imported. After that point, it's too late.
It's possible that we could somehow have SWIG put this into the generated _core.py only for GTK+3, but I'm not sure how to do that.
There is a similar crash that occurs when using a wx.Printer.
Anyway, I've spent considerable time investigating these and found that the crash is because GTK performs some dlsym() calls to lookup symbol names and fails in going so because its symbols were loaded in the local namespace, not the global namespace (ie, RTLD_LOCAL vs RTLD_GLOBAL). I've discussed this with the GTK devs and basically, GTK expects its symbols to be loaded globally.
Thus, I have a solution that I would like to propose for discussion:
# Load the package namespace with the core classes and such
+import dl, sys
+flags = sys.getdlopenflags()
+sys.setdlopenflags(flags|dl.RTLD_GLOBAL)
from wx._core import *
+sys.setdlopenflags(flags)
del wx
if 'wxMSW' in PlatformInfo:
===
Basically, this would change the dlopen flags before importing the core module to RTLD_GLOBAL and then change them back afterwards. That way, the core module and its dependencies (to include GTK) are loaded into the global namespace.
Comments on this proposal?
It needs more work but I wanted to get feedback before finalizing a patch. (ie, it probably only needs to be done on when we're using a GTK+3 backend, needs to check whether the dl module is available, etc.)
There is a similar crash that occurs when using a wx.Printer.
Anyway, I've spent considerable time investigating these and found
that the crash is because GTK performs some dlsym() calls to lookup
symbol names and fails in going so because its symbols were loaded in
the local namespace, not the global namespace (ie, RTLD_LOCAL vs
RTLD_GLOBAL). I've discussed this with the GTK devs and basically, GTK
expects its symbols to be loaded globally.
Thus, I have a solution that I would like to propose for discussion:
# Load the package namespace with the core classes and such
+import dl, sys
+flags = sys.getdlopenflags()
+sys.setdlopenflags(flags|dl.RTLD_GLOBAL)
from wx._core import *
+sys.setdlopenflags(flags)
del wx
if 'wxMSW' in PlatformInfo:
===
Basically, this would change the dlopen flags before importing the
core module to RTLD_GLOBAL and then change them back afterwards. That
way, the core module and its dependencies (to include GTK) are loaded
into the global namespace.
Comments on this proposal?
It needs more work but I wanted to get feedback before finalizing a
patch. (ie, it probably only needs to be done on when we're using a
GTK+3 backend, needs to check whether the dl module is available, etc.)
Okay, here's an updated version of the patch. Unfortunately, it isn't
possible to check the backend (and only change the dlopen flags if on
GTK+3) because the backend isn't known until _core.so is imported. After
that point, it's too late.
It's possible that we could somehow have SWIG put this into the
generated _core.py only for GTK+3, but I'm not sure how to do that.
Comments?
I'm curious how pygtk handles this. Have you checked there?
IIRC in the early days of OSX the default was the OSX equivalent of RTLD_GLOBAL, and it caused some hard to diagnose issues. The alternative at the time was a 2 level namespace and using that meant that extension modules couldn't find the Python C API functions, so it was even worse. So setting RTLD_GLOBAL worries me a bit.
Basically, this would change the dlopen flags before importing the
core module to RTLD_GLOBAL and then change them back afterwards. That
way, the core module and its dependencies (to include GTK) are loaded
into the global namespace.
Comments on this proposal?
It needs more work but I wanted to get feedback before finalizing a
patch. (ie, it probably only needs to be done on when we're using a
GTK+3 backend, needs to check whether the dl module is available, etc.)
Okay, here's an updated version of the patch. Unfortunately, it isn't
possible to check the backend (and only change the dlopen flags if on
GTK+3) because the backend isn't known until _core.so is imported. After
that point, it's too late.
It's possible that we could somehow have SWIG put this into the
generated _core.py only for GTK+3, but I'm not sure how to do that.
Comments?
I'm curious how pygtk handles this. Have you checked there?
PyGTK is GTK2 only. I don't think they started doing this dynamic UI
builder stuff until GTK3. In PyGObject (the recommended GTK3 replacement
for PyGTK), they basically do exactly this - dlopen all the GTK libraries
into the global namespace.
IIRC in the early days of OSX the default was the OSX equivalent of
RTLD_GLOBAL, and it caused some hard to diagnose issues. The alternative
at the time was a 2 level namespace and using that meant that extension
modules couldn't find the Python C API functions, so it was even worse.
So setting RTLD_GLOBAL worries me a bit.
I too am a bit worried about the impacts of RTLD_GLOBAL. Thus, I suggested a less risky workaround patch to wxWidgets for the Font Chooser crash - posted to the bug report. It could probably be used in the wxPython C++ code if the wxWidgets guys won't take it.