Librewolf browser will not run in Fatdog 8.11. (Solved: Required dependencies now available.)

[Null_ID]

Over the past year now I have grown to appreciate the Librewolf browser, or the "much better Firefox", as I like to call it now. Librewolf boots OK in Bionic and Fossa Puppies, however, in Fatdog 8.11 I get stonewalled right off the bat by this error message:

Code: Select all

XPCOMGlueLoad error for file /tmp/.mount_LibreWh8o6L3/libxul.so:
/tmp/.mount_LibreWh8o6L3/libxul.so: undefined symbol: gdk_wayland_window_get_wl_surface
Couldn't load XPCOM.

Can anything be done to remedy this situation?

Librewolf project here: https://librewolf-community.gitlab.io/

[Keef]

I've been running Librewolf on 811 and now 812. It won't run out of the box, but needs atk-bridge (and possibly another atk lib) which are available using Gslapt.

[Null_ID]

I've been running Librewolf on 811 and now 812. It won't run out of the box, but needs atk-bridge (and possibly another atk lib) which are available using Gslapt.

"Atk-bridge" by itself gives me nothing. Could you please identify the exact packages that I need?

[Keef]

You need 'at-spi2-atk'. Update gslapt (if not done recently) and searching for 'atk' will bring it up. Gtk3 is also needed.
This is using LibreWolf-78.0.1-1.x86_64.AppImage.
Not sure why you got the error message ' gdk_wayland_window_get_wl_surface', didn't get that on my system. Testing from a clean boot.

[step]

@Null_ID, take a look here. After installing gtk3 as @Keef pointed out, and running librewolf, if you still get that error message google for "XPCOMGlueLoad error" and see if any of the suggested remedies can help your case.

[Null_ID]

@Null_ID, take a look here. After installing gtk3 as @Keef pointed out, and running librewolf, if you still get that error message google for "XPCOMGlueLoad error" and see if any of the suggested remedies can help your case.

Yes, I'm aware of the GTK3 requirements. I took a look of that list of packages, and I already have most of them installed, since official Firefox requires them. I've now updated to the latest 8.12 Fatdoggy, so I took this opportunity to start a fresh system. I installed the listed packages 1-by-1, but nothing helps. The error message persists exactly as reported in my opening post. Now, here's what I have to point out:

LibreWolf-78.0.1-1.x86_64.AppImage.

User @Keef is running a MUCH older Librewolf at version 78, whereas I'm attempting to boot the very latest (at the time of this writing) version 94. There's been quite a bit of time between these two releases, and some things have probably changed. Some of Librewolf's internals have been reworked to behave differently. Now, the error message makes references to "wayland", as in the Wayland display protocol? Could it be that some of the GFX processing components needed to satisfy current Librewolf's wants and needs simply do not exist in current iterations of Fatdog?

I will continue to read about the "XPCOMGlueLoad error", but right now it's looking like I'll just have to resort to other dogs and puppies for my Librewolf needs. For now, thanks to all who tried to help.

[jamesbond]

The core problem: the most recent version of LibreWolf requires gtk3 that has been compiled with wayland support; and thus cannot run on Fatdog.

The remedy? I'm going to take the unpopular position, or position that sounds like blame-shifting, but I have to say it, because I believe I am correct.

________________

TL;DR: The problem is with LibreWolf AppImage packaging, and it should be reported to their forum.
You should report the issue in LibreWolf's forum/issue tracker and tell them the LibreWolf AppImage doesn't work with a system that does not have wayland installed.
________________

Now I'm going to explain why I take that position.

(1) The value proposition of an "AppImage" is to that it can run an all systems without worrying about dependencies. The AppImage should include __ALL__ the dependencies that it needs, except very basic ones that is guaranteed to exist in every system, like glibc.

(2) Now, of course there is an argument of what dependencies to include and what dependencies should be provided by the host system, but the point is, if you want to have your AppImage to be able to run in as many systems as you want, then the lesser you depend on the host system, the better.

For example, many Qt-based AppImages I have used does not even require you to have Qt installed. The AppImages themselves have Qt included (and sometimes, having a Qt installed can interfere, but that's a different matter which we can easily fix).

(3) So the ideal situation for LibreWolf is to have gtk3 included in their AppImage. But some may argue that only in fringe distros gtk3 is not installed by default; all modern distro have gtk3, so why bloat the size by including a library that is already provided by most host systems anyway? Well, see point (1) and (2) above.

(4) But even if we agree that gtk3 is commonly provided by host distro, then dependency on gtk3 does not automatically implies dependency on certain gtk3 features or dependency on how the gtk3 compiled on the host, this explicitly goes against the spirit of (1). Hence, depending on host gtk3 to have wayland support is definitely not the right approach to take, because while gtk3 is included in many host distros, wayland support (and thus gtk3 that has wayland support) is relatively new; and many fringe distros don't support it.

Which really comes back to bite at point (2). If the LibreWolf people needs gtk3 __with wayland support__, then really, rather than assuming the host distro have it, they should instead __package it into their own AppImage__. Otherwise, really, just specify the minimum requirement for their AppImage. (E.g., won't work on systems that don't have wayland), and in the process, excluding many systems, which at the end defeats the purpose of having an AppImage at all (1).

I don't think this is the case. I think the requirement of the gtk3 wayland support in LibreWolf is a mistake, a bug, rather than intentional, considering that even mainstream browsers standard distribution (i.e, non-AppImage version) of Firefox or Chrome does not even need wayland or gtk3 with wayland. Surely an AppImage is meant to be more compatible with more systems compared to a tarball?

[mikeslr]

Librewolf is a hardened firefox. It's advantage over firefox is that it's been hardened for you. But the people who did it didn't do anything your can't do yourself. Doing it is a PITA. But from the above posts maybe less of a PITA than trying to get Librewolf functional. And there's another benefit of starting with firefox and doing it yourself: firefox will update -- you only have to harden it once.

I started both this thread about LibreWolf, viewtopic.php?t=1491 and this one about hardening firefox, viewtopic.php?p=19203#p19203. Perhaps because I run multiple puppys --all using the same MikeWalsh's firefox-portable with two profiles (one for general browsing, the other hardened)-- I haven't used Librewolf since the above reported exploration.
To harden firefox essentially I followed Chris Xiao's instructions --linked to on the above post-- supplemented by 8Geee's recommendations posted on the thread it spawn.
Beats waiting for an organization hell-bent reducing the ability of its product to function in varied environments to change its ways. Pandas are interesting creatures. But look where that existential choice as gotten them.
Further recommendations to the How to Harden Firefox thread would be welcomed.

[mikewalsh]

@jamesbond :-

I honestly couldn't have put it better myself, Jim. Apps packed as AppImages are completely pointless if they won't run on as many systems as possible by default.....

Goes against the whole principle of an AppImage in the first place, and I STILL say they're better than Snaps or Flatpaks, both of which insist on a 'framework' ALREADY being in place before you can even think about installing/using/running them.

(Yes, I know that to many purists the AppImage is a ridiculous invention in the first place, and many simply cannot see the point of having more than one version of any given dependency on their system at all. But with the way so many 'puters are now coming OOTB with great gobs of RAM, huge amounts of storage and more frills'n'frippery than you can shake a stick at, complaining about extra space being consumed IS, frankly, a bit 'sad'...)

Mike.

[Null_ID]

Yeah, you guys, I don't think this is gonna work. Too much hassle. I decided to give it one last shot. Since I noticed that Fatdog prefers to use packages from Slackware, I headed over to Slackware's repo (https://slackware.pkgs.org), and pulled these from there:

Code: Select all

egl-wayland-1.1.7-x86_64-1.txz            kwayland-server-5.23.3-x86_64-1.txz
gtk+3-3.24.30-x86_64-1.txz                layer-shell-qt-5.23.3-x86_64-1.txz
kwayland-5.88.0-x86_64-1.txz             
kwayland-integration-5.23.3-x86_64-1.txz  wayland-1.18.0-x86_64-1_slonly.txz

These, at least on the surface, would seem to satisfy Librewolf 94's desire for Wayland enabled GTK3, however, this ultimately means nothing, because:

Code: Select all

XPCOMGlueLoad error for file /tmp/.mount_LibreW1fr3RO/libmozgtk.so:
/lib64/libm.so.6: version `GLIBC_2.29' not found (required by /usr/lib64/libgtk-3.so.0)

then I'm hit with the fact that the GTK-libs from Slackware require newer Glibs @ ver. 2.29, whereas Fatdog 8.12 only offers 2.27. At this point I'm all like "Nahh, forget it. Too much hassle". So, at this point I surrender and respectfully bow out. I'll leave this information here, just in case somebody else wants to play with it and maybe take the next step. As for me, hardening the official Firefox for use with Fatdog is starting to look like the easier way. Either that, or just stick to Fossa Pup, another great dog.

[Feek]

You can use Firefox in both of them (Fatdog and Fossa), with the same hardened profile.

The truth is that the hardening of the Firefox takes some time and effort (on the other hand you have control over the settings).
As mikeslr says it is a good idea to use 2 (or more) profiles - one strict and the other with normal settings.

Once the hardening is done and you are satisfied enough the profile can be easily copied between puppies or versions (of Fatdog).

[step]

(This is loosely related to the OP)
The news is that even the latest Tor Browser is having an issue with an unresolved wayland dependency issue/40963. This time gentoo and slackware are being hit, along with Fatdog64-812:

Code: Select all

libxul.so: undefined symbol: gdk_wayland_display_get_wl_compositor
Couldn't load XPCOM.

Let's see how soon a similar issue will creep up in another mozilla-based browser. Meanwhile, read the changelogs before upgrading your fav mozilla browser...

[jamesbond]

I have put libwayland to the repo and rebuild the latest gtk3 with wayland support.

To make it work, from gslapt:
1. Upgrade atk2 to 2.36.0 (the version installed in Fatdog is 2.28.1, this is too old)
3. Install libwayland (only libwayland is needed. "wayland-protocols" is not needed, that's a development tool).
2. Install gtk3-3.24.31. This is the version that supports wayland. (Don't use the older 3.22.30, it was not built with wayland support).

Actually, who am I kidding
Just launch gslapt and install/upgrade gtk3 to 3.24.31.
Gslapt will take care of the rest of the dependency.

I'm posting this from LibreWolf; but I suppose the solution should work with all apps with similar problem.
(The source of the problem is because those apps, when compiled, did not specify the linker flags -Wl,--as-needed).

[step]

I'm posting this from LibreWolf; but I suppose the solution should work with all apps with similar problem.

Confirmed it works for Tor-browser 11.0.0 - 11.0.3. Thank you.

[mikewalsh]

@jamesbond :-

TBH, it's become a case of 'follow-my-leader'.

While I agree with your position re: AppImages themselves, the fact of the matter is this:-

Red Hat have decreed that Wayland is the future. "This is the way it's going to be from now on. Take it or leave it. Xorg is dead...."

Instead of doing some head-scratching to come up with their own alternative, yet still 'compatible' workarounds, most distros are carefully treading in Red Hat's footsteps, and 'toeing the line'.................because it's so much simpler & easier to be one of the crowd, all nicely generic, homogenised and 'acceptable'. Everything guaranteed to work that way. Why make life hard for yourself?

Rather than the way it used to be - when individuality on this side of the fence was something to be admired & aspired to - the focus now appears to have switched to being as bland, generic and easy-to-live with as possible. By whatever means possible.

I know Red Hat have to a certain extent always dictated the general direction for the mainstream, yet I can't help feeling that IBM are beginning to exert some silent pressure in the background. They've got long memories, and still haven't forgotten the way MyCrudSoft conned them back in the late 70s/early 80s. I wouldn't put it past them to try and use Red Hat's position as 'de facto' leader of the pack to try and forcibly concatenate the whole of the Linux ecosystem into one single, user-friendly OS with killer, must-have features simply to get back at M$.

Maybe I'm reading more into it than is really there. Let's see what happens over the next 5 years or so, shall we?

Mike.

[jamesbond]

@mikewalsh

I wrote a very long article about this on my blog, but let me give you a simplified version.

FOSS has always been about do-ocracy. The more you do stuff, the more you are "valued". Those who do the most stuff, eventually rise up to the top, and become maintainers, elders, stewards, whatever you want to call it - and they get to decide what happens to the projects.

In the past it was mostly "volunteers" who did most of the heavy-lifting.
There no £££ involved, so motivations range from personal itch to personal pride.

This (generally speaking) worked well, because only genuinely interested person would work on FOSS projects, and they cared for that project because of their personal involvements. When they got at the top, they made decisions that (they thought) were best for the projects (they didn't necessarily get it right, not all the time, but its the intention that counts).

And nobody cared, because there was no £££ to be made from FOSS projects.
Until RH and MySQL made it to a billion dollar company club.

For the better or worse, this made companies - either friend or foe - to start looking at FOSS. And they started to put people (=paid employees) to work on FOSS projects.

Unlike the volunteers of old, these employees don't have genuine interest on the projects; they clock their time only because their bosses tell them to. Still, because they're now the "most prolific contributor" by whatever metrics you want to use (number of bugs fixed, number of lines written, etc), they too rise to the top. When they reach the top, however, they don't make decisions which are best for the projects. They make decisions which are best for their bossess (companies), naturally.

And companies rarely want to make FOSS projects better. All they care is how to make more money from them, because all those quids they pay their employees don't fall from the sky, hey?

As simple as that. As for the rest of us, "the peasant caste", as you said so eloquently, is "take it or leave it ..." and might I add, "... as we couldn't care !@#$% of what you think since you're not the paying customer anyway."

_____________

As for the AppImage/wayland stuff, my position doesn't change. Many Qt-based AppImage will run perfectly okay; and that's because they include the entire Qt-libraries in the AppImage. Why couldn't gtk3-based AppImages do the same, eludes me.

However, being the pragmatic and nice people that we are, we try to accommodate. I can argue my position with the LibreWolf developers until we're both red in the face, but the fact still exists that Fatdog users won't be able to use those AppImages until one of us do something.

Hence, since it's not too difficult to do it, I decided to build gtk3 that supplies those missing symbols (in other words, gtk3 that links with libwayland).

It doesn't mean that we support wayland or anything. We supply it just so that these oddball AppImages work.

And this is not the first time we do it either. I have libselinux in the repo. We don't use SELinux in Fatdog (it's an overkill for a desktop OS), but one of the AppImages requires it (looking at you, OpenShot. Yes, you. Tell me, what does a video editing program have to do with Secure Operating System???), so we build it for people who needs it.

It doesn't, however, mean that we will supply all missing libraries from all malformed AppImages. We consider this on case-by-case basis - as being a small team and doing this in our free time, we have other priorities in life. Unlike those paid employees

[Null_ID]

I have put libwayland to the repo and rebuild the latest gtk3 with wayland support.

To make it work, from gslapt:
1. Upgrade atk2 to 2.36.0 (the version installed in Fatdog is 2.28.1, this is too old)
3. Install libwayland (only libwayland is needed. "wayland-protocols" is not needed, that's a development tool).
2. Install gtk3-3.24.31. This is the version that supports wayland. (Don't use the older 3.22.30, it was not built with wayland support).

Actually, who am I kidding
Just launch gslapt and install/upgrade gtk3 to 3.24.31.
Gslapt will take care of the rest of the dependency.

I'm posting this from LibreWolf; but I suppose the solution should work with all apps with similar problem.
(The source of the problem is because those apps, when compiled, did not specify the linker flags -Wl,--as-needed).

Aah, an unexpected turn on events, but a most pleasant one regardless. And what a wonderful Christmas present it turned out to be. Thank you so much, good sir, for taking the time. Librewolf 95 is now up and running here as well on the latest 8.12 Fatdog.