libdir issues

[KaruroChori]

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.

• Recreate this issue in a simple reposiotry
• Report it upstream @ https://github.com/mesonbuild/meson
• Waiting for an upstream resolution

[andy5995]

Static linking all the libraries isn't an option?

[KaruroChori]

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]

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

[KaruroChori]

Reported as mesonbuild/meson#13931

[andy5995]

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]

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.