Mozilla binary fails to start on pure Wayland system (=without X11 libraries): XPCOMGlueLoad error for file /tmp/firefox/libmozgtk.so / libX11.so.6: cannot open shared object file: No such file or directory
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: manday, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0
Steps to reproduce:
At the risk of this being closed as WONTFIX or an equivalent, I would politely like to ask if Mozilla could provide certain variants of firefox-bin, notably a dedicated Wayland (only) build, which does not link against X11.
firefox-bin is the only one package which pulls in a large list of X11 dependencies on my system, including cairo with X11 support, and coincidentally causes conflicts on Gentoo's cairomm, too. I don't mean to assign blame by saying that, but just wish to express that there are in fact practical complications which are already solved by the code and could be used during deployment to everyone's benefit.
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•1 year ago
|
||
(In reply to Cedric from comment #0)
firefox-bin is the only one package
Please test if you are able to start the binary from https://nightly.mozilla.org on pure Wayland.
(To replace the Wayland icon with the Nightly icon you might want to create a firefox-nightly.desktop file: bug 1751153)
bug 1661450 has been fixed a year ago: You could ask Gentoo to provide an experimental Wayland-only package.
I mean this issue to be specifically about Mozilla providing a binary which is not linked against X11 libraries.
This is not about bug 1661450 which allows building it w/o X11 support. It is about the fact that Mozilla's releases do not build it w/o X11 support. Of course, someone else like Gentoo could do their own specific release (they most definitely will not, though), but I hope Mozilla might consider doing it.
Thanks!
|
|
||
Comment 4•1 year ago
|
||
It would be nice, but I doubt it because they (Mozilla) try to save money where they can.
There is still no official arm64 build.
To be able to enable MOZ_ENABLE_WAYLAND=1 by default in Beta and Stable (bug 1752398), users of the .tar.gz binary must be migrated to Debian packages (which must be made first: bug 1799516) and less preferably to Snap (slow startup, feature-breaking sandbox) and Flatpak (no system ffmpeg h264 possible = buggy openh264 is used).
Please test whether https://nightly.mozilla.org works on pure Wayland or not. If that is broken, it should be fixed first.
$ ldd firefox/firefox-bin
linux-vdso.so.1 (0x00007fff15bf3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f868cbbd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f868cbb8000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f868c800000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f868cad9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f868cab9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f868c61f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f868ccb5000)
I don't see any reason why it would fail on pure Wayland, since 112.0 also works fine. The problem is not that it will fail on pure Wayland, but that it will fail if the X11 libraries are not present! They do not appear on the ldd output, which is obviously incomplete (not even GTK or cairo show), but firefox will fail without them, perhaps from dlopen or via cairo.
I'll try the Nightly anyway if that helps.
FTR, with the nightly firefox-114.0a1.en-US.linux-x86_64, it starts fine on pure Wayland, but fails with the following message on pure Wayland without X11 libraries present:
XPCOMGlueLoad error for file /tmp/firefox/libmozgtk.so:
libX11.so.6: cannot open shared object file: No such file or directory
Couldn't load XPCOM.
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
|
|
||
Comment 7•1 year ago
•
|
||
Should be fixed now if you build with wayland-only build target.
ac_add_options --enable-default-toolkit=cairo-gtk3-wayland-only
Please reopen if that fails.
Thanks.
Hi, thank you very much for adressing this. I don't fully understand the implications, though.
The bug originally concerned the provision of a binary which runs without X11 libraries by Mozilla. Then I tried the Nightly as requested, which is the universal "runs on X11 and Wayland" version, which I suppose will not change.
Therefore the default-toolkit option is not going to be set to cairo-gtk3-wayland-only, because it (sounds like it) will not exclude X11.
Will there be a binary compiled with that switch? Or did I completely misunderstand and the Nightly should work without X11 libraries now, like I was told to try?
|
|
||
Comment 9•1 year ago
|
||
(In reply to Cedric from comment #8)
Will there be a binary compiled with that switch? Or did I completely misunderstand and the Nightly should work without X11 libraries now, like I was told to try?
You need to build your own Wayland only build with cairo-gtk3-wayland-only (Bug 1833855). I don't think Mozilla is going to provide such builds for you. Most of the Firefox is distributed by distros anyway so you may ask your distro to create Wayland only build (with all integration needed like search provider, icons, desktop files etc.).
Feel free reopen this one if you feel Mozilla should provide Wayland only build but I don't think it happens anytime soon.
|
|
||
Comment 10•1 year ago
|
||
I think third party build system may be used for it, like Copr for Fedora (https://copr.fedorainfracloud.org/). That allows to build distro rpm packages with different setup. You can take Fedora Firefox src.rpm and build that with different config.
|
Reporter | |
Comment 11•1 year ago
|
||
Yes, I would like to re-open this because that was my original intent. I was unaware that this wouldn't have been possible in the first place. But since now it is, maybe there is hope yet!
Description
•