Announcement: New/updated in HaikuDepot (2023)

CudaText/Python4Lazarus is already “using RTLD_GLOBAL” for the dlopen() call that loads libpython3.x.so. But it also uses RTLD_LAZY. I wonder if that might be causing the issue.

@Begasus, could you try changing line 3008 on python4lazarus/PythonEngine.pas to:

FDLLHandle := PtrInt(dlopen(PAnsiChar(S), RTLD_GLOBAL + RTLD_NOW));

Recompile that and CudaText, and see if that solves the missing symbols when using Python 3.9 when attempting to use plugins on CudaText?

That seems to be the only place were Alexey uses dlopen, so… worth a shot?

According to dlopen’s specs/docs:

RTLD_NOW
All necessary relocations shall be performed when the executable object file is first loaded. This may waste some processing if relocations are performed for symbols that are never referenced. This behavior may be useful for applications that need to know that all symbols referenced during execution will be available before dlopen() returns.


Even if that does fix it the issue, we might still consider doing whatever Python now does for Android/CYGWING, and make those modules link against libpython3.x.so.

The fact that Python originally didn’t link those modules to “libpython.so”, then it did for a few versions, then reverted back to not link them, only to shortly afterwards “undo” that for Android and then for CYGWIN… plus comments like this, leaves me wondering “what the heck?!?” we’re supposed to do here? :smiley:

For reference (if we need to patch our Python’s):

  • commit making CYGWIN behave like Android’s case here.
  • and fix up to that one here.
4 Likes