[Qt5] Saving by file dialog doesn't work (crash), undefined symbol: QTimer_singleShot3

[pintassilgo]

I just tried to save an untitled file. The normal dialog opened for me to choose the directory and file name. But on pressing Enter or clicking "Save", Cuda suddenly closes without actually saving.

File content doesn't matter, I tried with just a couple of normal letters and it was the same.

Additional info after some tests:

• latest GTK is fine.

• 1.199.0.0 Qt5 is good.

• 1.200.0.1 Qt5 is bad (so now you know when the issue was introduced).

• but for some reason, latest Qt5 from Flathub (1.204.0.0) is not affected.

• by running Cuda from terminal to get logs, this is what is printed when Cuda crashes:

    /home/user/cudatext/cudatext: symbol lookup error: /home/user/cudatext/cudatext: undefined symbol: QTimer_singleShot3
  

[Alexey-T]

The reason is that now (with newer Cud) you need updated libQt5Pas.
Ubuntu package for libqt5pas has too old library.
you need it from here
https://wiki.freepascal.org/CudaText#Linux:_Qt5_and_Qt6_builds

but for some reason, latest Qt5 from Flathub (1.204.0.0) is not affected.

So they use older Lazarus with older qt5 binding.

[pintassilgo]

I use openSUSE Tumbleweed, not Ubuntu. System is updated, it's done daily, it's a rolling release distro. I don't think I should update libraries off of the package manager, this can break things.

[Alexey-T]

Hi @davidbannon . As you see here, SUSE did not use your last libqt5pas package. What to do for user?

[pintassilgo]

Note: even downloading the libqt5pas-1.2.15-2.x86_64.rpm from here and placing libQt5Pas.so.1, libQt5Pas.so.1.2 and libQt5Pas.so.1.2.15 in Cuda folder, the issue still happens.

And jfyi, my /lib64 has libQt5Pas.so.1.2.9.

[Alexey-T]

and placing libQt5Pas.so.1, libQt5Pas.so.1.2 and libQt5Pas.so.1.2.15 in Cuda folde

on Linux, app does NOT use libraries from its folder. (on Windows - yes). you need the special command line when you put libraries to app folder, I forgot it: some 'ld' command?

[Alexey-T]

https://stackoverflow.com/questions/13428910/how-to-set-the-environment-variable-ld-library-path-in-linux
Using this LD_LIBRARY_PATH, add folder of Cud to the system PATH. then run Cud - it uses libs form app folder?

[pintassilgo]

LD_LIBRARY_PATH=. ./cudatext works.

But this looks a bit hackish and not a proper solution for those like me who want to use Cuda in a distro that doesn't have it in official package manager. So I download it from your releases and run it almost as a portable app, but if it needs some specific library that can be incompatible with the system version, there's an issue.

Shouldn't libQt5Pas be bundled in your Linux builds in a way that the software can use it directly instead of relying in system libraries?

I see that some other portable apps I have here have .so files in the same folder as the app, like Firefox and some games.

[Alexey-T]

What you suggest - is the dynamic loading of libqt5pas. With current Lazarus codebase it is not possible:

const
...
    Qt5PasLib = 'libQt5Pas.so.1';
...
function QObject_Create(parent: QObjectH = nil): QObjectH; cdecl; external Qt5PasLib name 'QObject_Create';
procedure QObject_Destroy(handle: QObjectH); cdecl; external Qt5PasLib name 'QObject_Destroy'; 
function QObject_event(handle: QObjectH; AnonParam1: QEventH): Boolean; cdecl; external Qt5PasLib name 'QObject_event';
function QObject_eventFilter(handle: QObjectH; AnonParam1: QObjectH; AnonParam2: QEventH): Boolean; cdecl; external Qt5PasLib name 'QObject_eventFilter';
procedure QObject_objectName(handle: QObjectH; retval: PWideString); cdecl; external Qt5PasLib name 'QObject_objectName';
procedure QObject_setObjectName(handle: QObjectH; name: PWideString); cdecl; external Qt5PasLib name 'QObject_setObjectName';
function QObject_isWidgetType(handle: QObjectH): Boolean; cdecl; external Qt5PasLib name 'QObject_isWidgetType';
function QObject_isWindowType(handle: QObjectH): Boolean; cdecl; external Qt5PasLib name 'QObject_isWindowType';
function QObject_signalsBlocked(handle: QObjectH): Boolean; cdecl; external Qt5PasLib name 'QObject_signalsBlocked';
function QObject_blockSignals(handle: QObjectH; b: Boolean): Boolean; cdecl; external Qt5PasLib name 'QObject_blockSignals';
function QObject_thread(handle: QObjectH): QThreadH; cdecl; external Qt5PasLib name 'QObject_thread';
procedure QObject_moveToThread(handle: QObjectH; thread: QThreadH); cdecl; external Qt5PasLib name 'QObject_moveToThread';
function QObject_startTimer(handle: QObjectH; interval: Integer; timerType: QtTimerType = QtCoarseTimer): Integer; cdecl; external Qt5PasLib name 'QObject_startTimer';
procedure QObject_killTimer(handle: QObjectH; id: Integer); cdecl; external Qt5PasLib name 'QObject_killTimer';

this is fragment of lazarus code. as we see, it is STATIC linking of library.

[davidbannon]

Hi @davidbannon . As you see here, SUSE did not use your last libqt5pas package. What to do for user?

Not much I am afraid. Most if not all Distros do not take the updated libqt5/6 libraries until they are formally released.
And, unfortunatly, Z does not want to release the libraries as standalone things, he wants to keep the libraries locked to Lazarus, so, until Lazarus 3.0 is released, they will not appear in any distro (maybe Arch ?).

Only option is for the user to manually download and install.

You should install (NOT extract the libraries and put them somewhere). If that does not work, its a bug in my packaging and should be reported there. I have recently tested them on OpenSuse, worked for me. Note you have to download and install the signature key too, its an OpenSUSE thing ....

Davo

[pintassilgo]

Most if not all Distros do not take the updated libqt5/6 libraries until they are formally released.

until Lazarus 3.0 is released, they will not appear in any distro (maybe Arch ?).

So Cuda relies on a library that isn't available in almost any distro, if not any. That doesn't sound good, it's a critical incompatibility issue. Cuda should probably downgrade to be usable with the released version or find a way to bundle the required version in the build.

[Alexey-T]

probably downgrade to be usable with the released version

It means i must use older Lazarus release, so I will miss last lazarus fixes (made after release)

or find a way to bundle the needed version in the build.

It is not nice to pack also some .so files, and user will anyway need to make the custom shell script like

cd <....>
LD_LIBRARY_PATH=. ./cudatext

soon the lazarus 3.0 will be released.

[davidbannon]

Don't be too hard on Alexey here, I do the same thing with tomboy-ng. If a user is comfortable downloading and installing a application package, it just as easy to download and install a matching library.

Alexey, I guess you sign the CudaText packages for the SUSE users ? Maybe it would help if we produced a set of libraries signed with the same key file ? They way, they only need install the one key file.

Davo

[2colours]

To be frank, it's far from comfortable to manually mangle dynamic library resolution and packages. In general, it's a huge QoL difference compared to, say, Geany where you do apt install geany and it just works, that you not only have to manually install Cudatext but even after you will have to chase after missing packages or else the apparently installed program will just crash. As others have said, it doesn't seem very secure or reliable either.

[Alexey-T]

difference compared to, say, Geany where you do apt install geany and it just works

The same is for CudaText GTK2 version.
Only Qt5 version needs packages.

btw, since the Lazarus 3.0 was released this week, all Linux distros must update libqt5Pas soon. Before they will do it, manual installation of libqt5Pas is needed.....

Avoiding libqt5pas on Qt5 version is out of my control

[kendofriendo]

This also happens with the AUR package, fyi.

[Alexey-T]

Yes, I know. I can only repeat:

since the Lazarus 3.0 was released this week, all Linux distros must update libqt5Pas soon. Before they will do it, manual installation of libqt5Pas is needed.

[pintassilgo]

• Arch: 2.6
• openSUSE: 2.6
• Ubuntu: 2.6
  ...

My humble suggestion is that for future releases Cuda should wait for major distros to update the packages before depending on them to not risk major breaks like this running issue.

[Alexey-T]

sorry, but waiting for distros (even major) is bad idea: lazarus evolves; so now lazarus requires libqt5pas 1.2.15 (AKA 2.15). to revert to libqt5pas 2.6 I must revert lazarus to old release too. but then I will miss latest lazarus changes/fixes.

[salvadorbs]

You should wait for the Lazarus Team to release a new release before using it in Cuda. Unfortunately, this means waiting years.

Or you could officially only support Flatpak and similar solutions, to have the dependencies directly in the Cuda package.

[davidbannon]

Just for the record, Debian Trixie has the current libqt5pas in its repo. It would seem very likely that Ubuntu, which takes packages from Debian Testing, will also have it in its next LTS - U24.04, April.
Other distros that take early debian packages will also get it too.
No sign of libqt6pas ...
Davo

[2colours]

Either way, I think it should be recognized that it's basic user quality of life to not have your installed software randomly crashing at you because of completely invisible external dependencies. What happens is simply not acceptable from user perspective. I needed to set up an editor quickly and I had to move to Geany because I had no time to start troubleshooting the editor. If I weren't dedicated to using Cudatext, I would have just moved on.

Something needs to be done. If this is such a known reason for crashing, why can't at least the program itself be defensive about it and say "this is likely to be the reason, follow the instructions here"? Having to install external dependencies manually is a hassle but the behavior (silent crash during basic functionality when the program seems to be installed) is a way bigger problem.

[Alexey-T]

What you want here is the Cud , compiled by old Lazarus release 2.x. sorry but I refuse to install additional Lazarus 2.x and make additional build for Qt5. Users can do it though, I may publish their release.

[2colours]

Well, it's mostly going to be your loss - if you even care about having users, that is...

[DUOLabs333]

I got bitten by this recently --- luckily, I'm mostly editing existing files, not making new ones.

[Alexey-T]

I added the call of QTimer_singleShot3 to the app initing. so if Qt5 lib is bad, program will crash on start.
Test it:
beta 1.208.8
#5377