Unable to load shared library 'libadwaita-1.so.0'

GlacierFox commented 1 month ago

Current behavior

Hi! Just downloaded the latest devtoys_linux_x64_portable.zip from the releases page and I'm getting an error when I'm trying to boot it.

Unhandled exception. System.TypeInitializationException: The type initializer for 'Adw.Application' threw an exception.
 ---> System.DllNotFoundException: Unable to load shared library 'libadwaita-1.so.0' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable: 
/home/danny/Apps/DevToys/libadwaita-1.so.0: cannot open shared object file: No such file or directory
/home/danny/Apps/DevToys/liblibadwaita-1.so.0: cannot open shared object file: No such file or directory
/home/danny/Apps/DevToys/libadwaita-1.so.0.so: cannot open shared object file: No such file or directory
/home/danny/Apps/DevToys/liblibadwaita-1.so.0.so: cannot open shared object file: No such file or directory

   at System.Runtime.InteropServices.NativeLibrary.LoadLibraryByName(String libraryName, Assembly assembly, Nullable`1 searchPath, Boolean throwOnError)
   at Adw.Internal.ImportResolver.Resolve(String libraryName, Assembly assembly, Nullable`1 searchPath)
   at System.Runtime.InteropServices.NativeLibrary.LoadLibraryCallbackStub(String libraryName, Assembly assembly, Boolean hasDllImportSearchPathFlags, UInt32 dllImportSearchPathFlags)
   at Adw.Internal.Functions.Init()
   at Adw.Module.Initialize()
   at Adw.Application..cctor()
   --- End of inner exception stack trace ---
   at Adw.Application.New(String applicationId, ApplicationFlags flags)
   at DevToys.Linux.LinuxProgram..ctor() in /home/etienne/Documents/repos/Publish/submodules/DevToys/src/app/dev/platforms/desktop/DevToys.Linux/LinuxProgram.cs:line 34
   at DevToys.Linux.Program.Main(String[] args) in /home/etienne/Documents/repos/Publish/submodules/DevToys/src/app/dev/platforms/desktop/DevToys.Linux/Program.cs:line 9
Aborted (core dumped)

I'm on RHEL 9.4 by the way, KDE 5.27, not sure if that makes a difference.

How to reproduce it (as minimally and precisely as possible)

Download the latest protable linux release.
Try to run it.

Expected behavior

For the app to run as normal.

Screenshots

No response

Workaround

No response

Affected platforms

Linux

Affected DevToys kind

DevToys (app with GUI)

DevToys Version

v2.0.4.0

Relevant Assets/Logs

No response

badcel commented 1 month ago

Hi, you need to have libadwaita installed.

GlacierFox commented 1 month ago

Hi, you need to have libadwaita installed.

Ah of course thanks, I assumed that was some Adwaita GTK only thing that would bring down tons of GTK stuff with it. I've installed that package but it seems I've ran into another problem.

(process:10046): Gtk-WARNING **: 11:44:35.244: Unknown key gtk-modules in /home/danny/.config/gtk-4.0/settings.ini

(DevToys:10046): GLib-GObject-WARNING **: 11:44:35.709: g_object_get_is_valid_property: object class 'WebKitWebView' has no property named 'web-context'
UnhandledException - unhandled exception: System.DllNotFoundException: WebKitGTK could not be found. Please verify that the package 'libwebkitgtk-6.0-4' is installed on the operating system and retry.
   at DevToys.Linux.Components.BlazorWebView.CreateWebView() in /home/etienne/Documents/repos/Publish/submodules/DevToys/src/app/dev/platforms/desktop/DevToys.Linux/Components/BlazorWebView/BlazorWebView.cs:line 200
   at DevToys.Linux.Components.BlazorWebView..ctor(IServiceProvider serviceProvider, Boolean enableDeveloperTools) in /home/etienne/Documents/repos/Publish/submodules/DevToys/src/app/dev/platforms/desktop/DevToys.Linux/Components/BlazorWebView/BlazorWebView.cs:line 86
   at DevToys.Linux.MainWindow..ctor(IServiceProvider serviceProvider, Application application) in /home/etienne/Documents/repos/Publish/submodules/DevToys/src/app/dev/platforms/desktop/DevToys.Linux/MainWindow.cs:line 50
   at DevToys.Linux.LinuxProgram.OnApplicationActivate(Object sender, Object e) in /home/etienne/Documents/repos/Publish/submodules/DevToys/src/app/dev/platforms/desktop/DevToys.Linux/LinuxProgram.cs:line 84
   at GObject.Signal`1.<>c__DisplayClass11_0.<Connect>b__0(Value returnValue, Value[] parameters)
   at GObject.Closure.InternalCallback(IntPtr closure, IntPtr returnValuePtr, UInt32 nParamValues, IntPtr paramValuesData, IntPtr invocationHint, IntPtr userData)

I need libwebkitgtk-6.0-4 but it looks like it's not available on RHEL unfortunately. I've done a repository search but I'm not sure any of the results provide the correct dependency.

sudo dnf search webkit
Updating Subscription Management repositories.
Last metadata expiration check: 1:54:05 ago on Fri 19 Jul 2024 09:54:44 BST.
==================================== Name & Summary Matched: webkit =====================================
kf5-kdewebkit.x86_64 : KDE Frameworks 5 Tier 3 integration module for QtWebKit
kf5-kdewebkit-devel.x86_64 : Development files for kf5-kdewebkit
kwebkitpart.x86_64 : A KPart based on QtWebKit
libproxy-webkitgtk4.x86_64 : Plugin for libproxy and webkitgtk3
obs-studio-plugin-webkitgtk.x86_64 : OBS Browser source plugin based on WebKitGTK
qt5-qtwebkit.x86_64 : Qt5 - QtWebKit components
qt5-qtwebkit-devel.x86_64 : Development files for qt5-qtwebkit
webkit2gtk3-devel.i686 : Development files for webkit2gtk3
webkit2gtk3-devel.x86_64 : Development files for webkit2gtk3
webkit2gtk3-jsc.x86_64 : JavaScript engine from webkit2gtk3
webkit2gtk3-jsc.i686 : JavaScript engine from webkit2gtk3
webkit2gtk3-jsc-devel.i686 : Development files for JavaScript engine from webkit2gtk3
webkit2gtk3-jsc-devel.x86_64 : Development files for JavaScript engine from webkit2gtk3
========================================= Name Matched: webkit ==========================================
webkit2gtk3.x86_64 : GTK Web content engine library
webkit2gtk3.i686 : GTK Web content engine library
======================================== Summary Matched: webkit ========================================
chromium.x86_64 : A WebKit (Blink) powered web browser that Google doesn't want you to use
geany-plugins-webhelper.x86_64 : Preview and Debug Web documents from within Geany using WebKit
libwpe.x86_64 : General-purpose library for the WPE-flavored port of WebKit
libwpe.i686 : General-purpose library for the WPE-flavored port of WebKit

badcel commented 1 month ago

Sorry I can't help you with this question as I never used RHEL myself.

But if they ship GNOME I would think that they ship WebKit, as it is used for Epiphany (aka GNOME Web) and probably Evolution (Email Client).

There was some incompatible API break in WebKit several years ago. You need to have this new version (the one you mentioned).

GlacierFox commented 1 month ago

@badcel ah thanks for the help anyway. It's probably due to RHEL having old packages or something. It does ship with GNOME by default but it's probably quite a bit behind the more up to date distributions.

veler commented 1 month ago

Hi @badcel ,

Thanks for helping finding a solution for @GlacierFox . Do you have any recommendation for me on how to handle this in the future? I'm thinking perhaps the app could try to detect on startup whether the dependencies are installed, and let the user know what he should do if they're not. I'm not exactly sure how to do that in an efficient (performance-proof) manner though.

What do you think?

badcel commented 1 month ago

Hi,

this is not an easy question. It depends on your Linux strategy:

If you want to publish some portable version you probably want to check if some dependencies are missing and report this clearly to the user. This approaches probably is the most uncommon one for Linux users and developers: Even if you check for the dependencies as far as I know different distributions package their binaries in packages which can have different names or binaries can be grouped together in packages. Additionally binaries can be compiled with different compiler flags or feature sets enabled. And just because it can even get more complex, the names of the binaries themself can vary between distributions. I think all this stuff got better over time and distributions get more similar over time as there are standards which for example define which kind of binaries should be in which folder (which was different between distros, too). So in theory you could check what is missing and either detect if there is some alternative available or let the user configure it or similar. But GirCore currently is build for the GNOME flatpack runtime. This means there is a very specific binary name expected. Either it matches or not. I'm open to allow to define alternative binary names but won't support automatic detection by GirCore. Additionally this feature would need to be contributed as it would be totally unsupported from my side. Using some random binaries with nuget packages build for a certain target will have a whole lot more of potential problems which are fully located on the users side. I'm not willing to spend this time to investigate problems. There were already some discussions but those users were better of compiling their own custom GirCore binaries as they control the whole distribution stack (windows OS).
A more common approach is to provide packages like you already do. Here similar problems apply like before but on a smaller scale because you can define your dependencies. But again those names can vary between distributions and creating for example a *.deb makes life harder for distros using different package manager like rpm / pacman / ...
From my point of view the most developer friendly eco system is flatpak. There are flatpak runtimes (e.g. GNOME SDK), which bundle certain libraries like the standard gnome stack. Those don't get distributed with your package as it depends on the runtime which can be updated separately. This system ensures the user can get security updates without forcing yourself to watch all dependencies. At the same time you can be sure that all dependencies are available on any host independently of the distribution. So no matter if it is rpm or apt based, or having no GNOME installation at all it just works. An alternative would be snap which is a lot more coupled to Ubuntu (probably more in people's mind than in reality). I don't have any experience with it as it is quite uncommon to use for fedora. Of course there are people who don't like snap and there are people who don't like flatpak and there are people who don't like both. From my point of view flatpak is the way to go as it more spread across distros, solves a lot of problems, provides a central store (flathub) and enables developers to take application distribution into their own hands. Disclaimer: I never created a flatpak myself but I plan, to publish one some day.

probonopd commented 1 month ago

Please avoid using libadwaita. libadwaita doesn't work well outside of the Gnome desktop, reduing the potential user base for this application.

badcel commented 1 month ago

Please avoid using libadwaita. libadwaita doesn't work well outside of the Gnome desktop, reduing the potential user base for this application.

Can you open a separate issue for this as it is not related to this report.

veler commented 3 weeks ago

Hi, I have a PR here that should help with this issue: https://github.com/DevToys-app/DevToys/pull/1380

DevToys-app / DevToys