Linking To Flatpak SDK Libraries

[csnazell]

Hi,

I'm currently playing around with Gir.Core on Fedora Silverblue.

I've been able to build and debug a sample app in a distrobox container if I use dnf to install the necessary GNOME libraries into the container. I've also been able to turn the app into a flatpak.

Ideally I'd like to be able to build and debug the app against the libraries in the GNOME sdk installed via Flatpak so any apps I develop are being developed against the SDK's libraries rather than the distro's packages. I've set up another container with dotnet and the requisites for running Rider but without the GNOME libraries. As expected, debugging a sample app fails due to the native libraries not being present. Adding LD_DEBUG=libs to the environment variables lets me see that by default dotnet is looking at /etc/ld.so.cache, /lib64 and /usr/lib64 by default.

I've tried adding an entry for LD_LIBRARY_PATH into the environment variables section of the project configuration in RIder. When I do this, pointing at the GNOME sdk libraries, I can see the relevant libraries being loaded but the app doesn't display a window and Rider's debugger fails to attach. I'm guessing this is interfering with something in dotnet-land.

Is there a way to add additional native library search paths to dotnet that's less heavy handed than LD_LIBRARY_PATH?

Any suggestions gratefully received.

[badcel]

Great to hear that it works with distro box.

I wonder what is going wrong here. Do you have the output of the app of it runs from the terminal and does not display a window?

In general there is just the way dotnet does library loading or a dev can roll their own.

But I don't interfere with those things except that I define the name of the library to load depending on the operating system.

There is issue #963 which covers the topic of custom loading.

Currently i tend to believe that you have some other problem. If you create a sample app in C itself in your current environment does it work like intended?

[csnazell]

Thanks for the speedy response. I suspect you're right that the problem is something else. Thanks for the help. I'll report back when I get to the bottom of it.