Hey - keen to try it, but it crashes on launch every time I try to run it. I rebooted to make sure 
- does it work on nightlies?
Please send me a bugreport for investigation
Updated 32bit version for CudaText (1.195.0.6) now availabe in the depot. 
Created with fpcupdeluxe (latest version also updated recently) → lazarus → cudatext_up sources:
Update! CudaText 1.195.0.6 now also available for 64bit
Both architectures need python3.7 still, had no real success bumping newer python version (without having to use LD_PRELOAD or the likes to launch it) 
18 Likes
WIP *
Almost there (building with Qt6 solves the crash when opening Preferences, maybe a bug in our Qt5 port?):
9 Likes
I think I found two issues with our Python packages:
-
None of our python versions provide (at least as a symlink)
/system/lib/libpython3.x.so(x=7m, 8, 9, 10, etc), but only/system/lib/libpython3.x.so.1.0(as a symlink to/system/develop/lib/libpython3.x.so.1.0).This prevents CudaText from autodetecting the installed Python(s), and thus require setting
pylib__haiku=/system/develop/lib/libpython3.x.soas part of the build process (or changing that fromuser.jsonin CudaText user settings). -
Using
ls *.so | xargs -L1 readelf -d | grep libpython3 | wc -lunder each/system/lib/python3.x/lib-dynloaddir shows that for Python 3.7 all those .so (Python’s C extension modules) are linked againstlibpython3.x.so(output of the command is “65”, same as the number of .so files), but none of the other versions do so (output “0”).I am assuming that we didn’t notice any issue, as we almost always use
/bin/python3.x, which IS linked against the correspondinglibpython3.x.soof course, and when we import C extension modules, we do so from inside /bin/python3.x’s process (with the libpython3.x.so already loaded).I’m guessing that those C extension modules not explicitly linking with libpython3.x.so, is what’s causing CudaText to give those “resolve symbol” errors, not at startup, but only when it tries to load a plugin that needs those modules (and thus why using
LD_PRELOAD=/system/develop/lib/libpython3.x.so CudaTextworks).
Guess I’ll have to take the plunge, and do some “./configure / Makefile” spelunking. Diffing Makefile.pre.in will be “fun” .
Hopefully someone else beats me to the punch, or point out how silly and wrong I am, and points to a proper solution. Either would be awesome 
2 Likes
Could very well be, allthough I already tried pointing to /boot/system/lib/libpython3.9.so.1.0 in the source (which should override using the libpython.so in the develop directory) with no succes (same outcome every time. Thanks for brainstorming on this!
Relevant Python issues:
And from What’s New In Python 3.8 — Python 3.8.18 documentation :
On Unix, C extensions are no longer linked to libpython except on Android and Cygwin. When Python is embedded,
libpythonmust not be loaded withRTLD_LOCAL, butRTLD_GLOBALinstead. Previously, usingRTLD_LOCAL, it was already not possible to load C extensions which were not linked tolibpython, like C extensions of the standard library built by the*shared*section ofModules/Setup.
So… not sure if that should be fixed on CudaText side (on its python4delphi component, perhaps), or if we have to do as Android/Cygwin, and revert back to what what was done up to Python 3.7.
One of the posts from the links above makes me want to give the later option a go.
1 Like
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?
For reference (if we need to patch our Python’s):
4 Likes
Whoot!!!
No more errors show also when launched from Terminal! 
Thanks @BiPolar !!!
EDIT @BiPolar Maybe create new packages that supports python3.9?
10 Likes
It would be good if you can do so, yes.
Otherwise I’ll need to add CudaText to the “list of shame” (things still using Python 3.7)" 
IMO, CudaText [1] should be modified so it looks for libpython3.x.so.1.0 [2] (for different values of x), so it picks up the symlink we already provide in /system/lib/, and not use hardcoded /system/develop/lib/libpython3.x.so
[1] on python4lazarus component I presume. It would make setting a default value for pylib__haiku unnecessary, if it can find it on its own.
this line looks promissing. I’d change it to: Result := 'libpython' + SysVersion + '.so.1.0';
And perhaphs also modifying lines inside this {$ifdef _so_files} accordingly.
[2] Could be simplified to libpython3.x.so if/when our Python packages provide such symlink.
That way, the CudaText package can be made independent of the Python version (it is not a hard REQUIRES, as it runs without libpython, albeit with no access to plugins, of course).
Sorry for not doing this myself, I try to stay away of all the mayor/big/complicated dependencies (GTK/Qt/Lazarus/etc). Too much for my PC/internet/patience/skills
This is what I’ve got atm:
diff --git a/python4lazarus/PythonEngine.pas b/python4lazarus/PythonEngine.pas
index ffa5446..f43dd0c 100644
--- a/python4lazarus/PythonEngine.pas
+++ b/python4lazarus/PythonEngine.pas
@@ -3005,7 +3005,7 @@ begin
FDLLHandle := Windows.LoadLibrary(PChar(S));
{$else}
//Linux: need here RTLD_GLOBAL, so Python can do "import ctypes"
- FDLLHandle := PtrInt(dlopen(PAnsiChar(S), RTLD_LAZY+RTLD_GLOBAL));
+ FDLLHandle := PtrInt(dlopen(PAnsiChar(S), RTLD_GLOBAL + RTLD_NOW));
{$endif}
end;
end;
diff --git a/app/proc_globdata.pas b/app/proc_globdata.pas
index 3e80803..f546a19 100644
--- a/app/proc_globdata.pas
+++ b/app/proc_globdata.pas
@@ -1335,11 +1335,9 @@ begin
{$ifdef haiku}
{$ifdef CPU64}
- exit('/boot/system/develop/lib/libpython3.7m.so');
+ exit('/boot/system/lib/libpython3.9.so.1.0');
{$else}
- exit('/boot/system/develop/lib/x86/libpython3.7m.so');
+ exit('/boot/system/lib/x86/libpython3.9.so.1.0');
{$endif}
{$endif}
@@ -1627,8 +1625,8 @@ begin
AppDir_Py:= OpDirLocal+DirectorySeparator+'py';
AppDir_Data:= OpDirLocal+DirectorySeparator+'data';
{$ifdef haiku}
- AppDir_Py:= '/boot/system/data/cudatext/data';
- AppDir_Data:= '/boot/system/data/cudatext/data';
+ AppDir_Py:= '/boot/home/config/non-packaged/data/cudatext/py';
+ AppDir_Data:= '/boot/home/config/non-packaged/data/cudatext/data';
{$endif}
AppDir_Lexers:= AppDir_Data+DirectorySeparator+'lexlib';
AppDir_LexersLite:= AppDir_Data+DirectorySeparator+'lexliblite';
I’m guessing @roiredxsoto did the initial upstream patches here for libpython3.7m.so?
This should be enough to get it to work for python3.9.
No expert here, but it should be good enough for my skills to get things up and running for the “default” python version.
EDIT forgot to mention that I needed to set the right python version in the default.json file too (otherwise that points to python3.7 still and will show up in the options dialog).
1 Like
Making it require/work-with Python 3.9 for now sounds OK to me.
Guess that if it bothers me enough, at some point I’ll gather the dependencies and test myself the suggested changes .
Thanks for your work Begasus!
1 Like
Small update, packages have been rebuild on buildmasters and are now available for both arch’s, this should complete the process for now having it using python3.9, thanks so far @BiPolar (and if you got the time and bandwidth there probably comes a better solution then this).
2 Likes
Iaito, officail Qt frontend for radare2, after updating radare2 (and a mention about iaito on the issue at haikuports) I’ve been looking into building a package for Haiku.
Now it’s here! A few downsides still, translations can’t be installed (iaito crashes when they are installed), no luck on fixing the crash when trying to launch from Tracker/Deskbar (has to be launched from Terminal for now).
This could use an icon too, a svg is included in the source but can’t be converted to rdef (out of range), so anyone with skills …
8 Likes
TuxRacer finaly reveived (long outstanding issue at haikuports), this could use a nice icon too.
Notes (long outstanding issue at haikuports also), currently got an icon but could use one more Haiku style.
XRick launch from Tracker/Deskbar fixed (closed an old issue for that too), available on 64bit too now.
PCManFM got an update (after updating depending libraries):
Updated FCEUX 64bit only for now (could use a nice icon too)
LGeneral got a fix for libSDL (as many others in the last days) and a build fix, it’s now available on 64bit also. (could also use an icon)
Last one in the line of fixing libSDL references, Heroes, recipe changes included sound files and now also available on 64bit! (Game launches in fullscreen, but you switch easaly with Alt-Enter to windowed mode).
Exult 1.8 (Ultima7 engine), now availabe in the depot for 32bit and 64bit (fixes long outstanding issue):
Copy your original game data to ~/config/non-packaged/data/exult directory to play.
New (older issue) an outstanding PR that was lying around and is fixed now, LDmicroqt:
Thanks for the groundwork from @3dEyes and @mazbrili !
26 Likes
wow… cool… big thanks @Begasus 
1 Like
Thank you @mazbrili for the original PR!
1 Like
We have the original exult (32bit) files with description on our repo over years, but no one take notice of that
2 Likes
I was bumping into this from the open issues at haikuports when I fixed this, didn’t look elsewhere, sorry
EDIT: for the record, created a PR upstream to fix the paths for Haiku
