search

KaruroChori / vs-fltk

Lightweight UI framework powered by fltk & scripting via tcc, quickjs, lua & wamr.
Other
2 stars 1 forks source link

`libdir` issues #3

Open KaruroChori opened 4 days ago

KaruroChori commented 4 days ago

There is a difference in behaviour between the library directory used by meson, and that used by CMake through meson. On my debian system for example, libraries generated by meson are moved into /usr/lib/x86...../ which is the right place. CMake via meson instead is placing them in /usr/lib. There is as similar issue on the freedesktop 24.08 image of flatpak. Meson places its libraries in /app/lib/ while CMake tries to place them in /app/lib64 which is wrong.

This issue is preventing the proper installation of vs and to build the flatpak image correctly.

andy5995 commented 3 days ago

Static linking all the libraries isn't an option?

KaruroChori commented 3 days ago

Sadly this is not possible. I could statically link some libraries like tinycc, quickjs or lua, but in most cases it would be either impractical or outright impossible.

Custom native components are supposed to be lightweight for distribution and to keep a small memory footprint. At the very least they all need to link libvs-fltk and libfltk; possibly more, as I would like to avoid the need for end users to install further dependencies once vs is ready and running on their machine.

KaruroChori commented 2 days ago

Demo repo in https://github.com/KaruroChori/meson-report-error

KaruroChori commented 2 days ago

Reported as https://github.com/mesonbuild/meson/issues/13931

andy5995 commented 1 day ago

I hope you don't mind if I give potentially outlandish ideas while trying to brainstorm a solution:

I have a little experience packaging for a few different Linux distributions, and for AppImage creation. In a packaging script, such as FlatHub, would it be possible, feasible, or practical to: after installing, move the libs to their appropriate directories, and then use patchelf to update where the libraries are being looked for? An example of how I use patchelf for the 0ad AppImage

KaruroChori commented 1 day ago

While possible, those would be more like workarounds. Your approach would surely work to get v0.1.1 out of the oven, but it would only delay the point this has to be solved straight few weeks ahead.

In short, the pipeline to patch binaries would be very messy if not outright impossible.
An important part of vs are custom native components, which are shipped as dynamic libraries and must dynamically link some of those generated in here which are affected by this bug. It is important to stress that native components are not even meant to be hosted and distributed by this repo for the most part.