UVviewsoft forums

CudaText 1.232.0.4, linux-x86_64-qt6, fpc 3.2.3

I finally have CudaText running native Wayland. Qt offers many environment variables. I tried them to no avail. What finally did the trick was a cli switch:
GTK3 in Lazarus 5.0 will do native Wayland for that widget set. I prefer GTK over Qt, but now run Qt6 for Wayland. Lazarus-based Double Commander has this discussion:
https://github.com/doublecmd/doublecmd/discussions/1097

The same cli switch runs Double Commander in native Wayland. I like how Double Commander ships libQt6Pas.so.6 out of the box. I wish Cud would do the same. Thanks!

why user don't download libQt6pas and install them to system dirs?

If I understand the question, it asks what is wrong requiring users to download and install the Qt Pascal lib to the sys dir.

* The user must have admin privs; not likely in multiuser (and/or thin client) corporate settings.

* Some Linux distros don't package Qt Pascal libraries. Void only packages qt5pas; no qt6pas exists in Void repos. So the option to install per Linux methods will not help everyone. Even when Linux does package something, it is not always the most recent release.

* The user must know what he is doing. Modifying system libraries is not something normally asked of users.

* System hygiene. I used LD_LIBRARY_PATH in a launch script. Even pro users and devs do not like modifying sys dirs behind the OS.

* Some future Cud version needs an updated lib, but the user thinks he already did the step, so Cud won't work. In other words, the requirement is not one-time. Eventually Qt7 will come. Shipping the lib with Cud makes it always work, out of the box.

* Making the user's life easier, not harder, is good practice, and spreads Cud popularity.

* Bundling the Qt5 and Qt6 Pascal libs with the respective Cud tarballs is almost no added work, just packaging logistics.

* Bundling the lib makes Cud a "portable app" on Linux. Copying the folder to another computer will "just work."

Thanks!

thanks for reasons. I see it is good to make so. I modified the setup script. so Qt5/Qt6 .xz distro package will include .so-file and 'cudatext.sh'.

DT_RUNPATH in the ELF would be cleaner than a wrapper script.

The key here is to use the DT_RUNPATH, which can be embedded into the binary you are creating. You can link it so that it points to the same directory, as you wanted.

I run many other wrapper scripts. Finding their execution directory is a common need. The best answer is an Explicit Recap of a discussion thread, And for Cud I also use which now I can point at the shipping library.

But DT_RUNPATH would eliminate a wrapper for most people. I could eliminate LD_LIBRARY_PATH mods from mine.

Thanks!

DT_RUNPATH - I don't know yet how to glue it to my linker program. but more important is this - I want to allow .so-files in system dirs too. so single binary 'cudatext' must work when so-file exists in app dir or not, when binary is in the DEB pkg or not.