reimar added the comment:
I guess one way this could be "solved" would be by libpython doing a dlopen on
itself with RTLD_GLOBAL on Python initialization.
I wouldn't bet that that wouldn't end up with some very interesting unintended
consequ
reimar added the comment:
I'm not sure how I can explain it much better, I even wrote example code after
all, but I'll try...
> So if you are embedding python by dlopen'ing libpython.so
Neither me nor Laszlo are using/embedding or otherwise involving Python
(directly/inte
reimar added the comment:
The modules not linking against libpython CAUSES this issue, thus Debian being
affected even for old Python versions before issue21536.
--
___
Python tracker
<https://bugs.python.org/issue36
reimar added the comment:
Sorry for my laziness. I opened Issue36753.
--
___
Python tracker
<https://bugs.python.org/issue34814>
___
___
Python-bugs-list mailin
New submission from reimar :
Most affected platforms: RedHat and Debian, but with the changes from
issue21536 probably all Linux distributions will be affected.
issue34814 and issue21536 and
https://bugzilla.redhat.com/show_bug.cgi?id=1585201 make statements along the
lines of "In
reimar added the comment:
As explained in Issue34814, this change not only breaks RTLD_LOCAL of
libpython, but it breaks it in fact system-wide.
It seems a bit much for Python to enforce a system-wide policy to not use
RTLD_LOCAL just because of its own technical challenges, and thus I'
reimar added the comment:
> In short, RTLD_LOCAL is not supported.
I am sorry, this is not a workable stance.
This does not just affect loading libpython directly.
It also affects dlopen of a library that links to a library ... that links to
libpython.
For a developer is impossible to k
