The default bug view has changed. See this FAQ.

Status

()

Core
Graphics
P5
enhancement
6 years ago
5 days ago

People

(Reporter: Michael, Unassigned)

Tracking

(Depends on: 14 bugs, Blocks: 3 bugs, {leave-open})

Trunk
All
Linux
leave-open
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ leave open for tracking ], URL)

Attachments

(2 attachments, 5 obsolete attachments)

(Reporter)

Description

6 years ago
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre

Currently, Linux, as well as other FOSS operating systems, uses X. A replacement for X is currently being developed called Wayland. It would be nice if when Wayland comes out, Firefox would be ready and support Wayland without needing X.

Reproducible: Always




Wayland won't be ready for widespread use for some time. As I understand it (which may be slightly inaccurate), even after it is ready for widespread use, it'll still be used to talk to X in order to speed things up. It'll probably be even longer before Linux desktops are able to ditch X altogether.
Component: General → Widget
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk

Comment 1

6 years ago
I think what you are proposing is a really good idea that would make FF even more popular between FOSS users.
(Reporter)

Comment 2

6 years ago
It seems that Google is working on porting Chrome to Wayland according to Phoronix.
http://www.phoronix.com/scan.php?page=news_item&px=OTc4NA
Mozilla will probably have to port it's products at some point in order to stay competitive on Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

5 years ago
Depends on: 627699
Component: Widget → Graphics
QA Contact: general → thebes

Comment 3

5 years ago
It looks like firefox uses GTK, which should make this easier.  GTK 3.4 supports wayland 0.85.  The page with instructions to build GTK with wayland support also has a "Porting your GTK+ application" section: http://wayland.freedesktop.org/gtk.html

I guess I'll just paste the whole thing here:

The GTK+ port to Wayland has some major functionality gaps. Porting of applications at this stage should simply be to start identifying where applications makes API calls that will not function under Wayland.

    * Ensure that your application uses gtk+-3.0 for its pkg-config request.
    * Your application must not use any API in the gdk_x11_ namespace or any raw Xlib calls.
    * Check the errata below for issues that might affect your application.

API to access the underlying wl_surface, wl_shell_surface and wl_display may be available in later versions of the code but are not available right now.

Comment 4

5 years ago
Note that a live CD allows to test applications on Wayland http://phoronix.com/forums/showthread.php?69394-Wayland-s-Weston-Lands-In-Ubuntu-12-04-LTS&p=254064#post254064

Comment 5

5 years ago
Other gtk applications are handling this by wrapping xlib calls in "#ifdef GDK_WINDOWING_X11".  I'm curious how much of the gecko gtk3 work could be handled this easily, and how much would require something more involved.

Comment 6

5 years ago
Similar work on gnome-terminal: https://bugzilla.gnome.org/show_bug.cgi?id=673323

Comment 7

5 years ago
Mozilla stuff is not a "gtk application", we only use GTK for a few specific things like getting the theming of our XUL widgets right. Our work to remove direct usages of X Bitmaps and go for GL for everything is way more relevant to potentially running on Wayland than any GTK stuff is.

Comment 8

5 years ago
"#ifdef GDK_WINDOWING_X11" is only a build time check, so it's insufficient.  A run time check is also needed, something like "if (GDK_IS_X11_DISPLAY (display))", documented here:  http://developer.gnome.org/gtk3/3.3/ch24s02.html#id1502079

There are also GDK_IS_X11_SCREEN and GDK_IS_X11_WINDOW.

Comment 9

5 years ago
Robert: Outputting directly via GL sounds lovely, where can I find more info on that effort?  Is there a bug open?

Comment 10

5 years ago
(In reply to Darxus from comment #9)
> Robert: Outputting directly via GL sounds lovely, where can I find more info
> on that effort?  Is there a bug open?

AFAIK there are multiple bug open for that, probably blocking some "enable OpenGL layers by default" bug, just search for OpenGL stuff here in Bugzilla and you should find a few.
(Note that I'm no code, just an interested community member, so I don't know all the details, but I usually have some rough grasp of the overview.)
The ongoing work to stop using X pixmaps directly is an important prerequisite for this. Marking as blockers.
Depends on: 720523, 738937
Depends on: 788319

Comment 12

4 years ago
What about starting from Mobile Firefox? On a tablet it's pretty much like a desktop browser (indeed without some of the bloat of classic desktop Firefox), and porting from Android should be simpler than disentangling the X/GTK mess (I bet Android Firefox doesn't use xpixmaps for example!).

Updated

3 years ago
Depends on: 943407

Updated

3 years ago
No longer depends on: 943407
Depends on: 1015218
Created attachment 8445763 [details] [diff] [review]
Hacks to get firefox on wayland

I recently looked at this. I tried to get Firefox-gtk3 running on Weston, using hacks wherever needed to avoid X11 calls / paths. After those bunch of hacks (which obviously would need to be done properly), I managed to get Firefox running on Weston, not without issues. More work is needed to turn those hacks into proper checks, to add suitable codepaths for wayland where necessary, and to fix regressions / bugs.

The attached patch is what I used, which as I said is quite hacky. This was tested on top of r186206. Perhaps various / most of those tests aren't necessary if MOZ_X11 is forced to 0 in configure.ac, I didn't try that. In any case, support for both X11 and Wayland in the same binary would be desirable, with runtime detection checks to pick one path or the other.
Created attachment 8445765 [details]
Screenshot of firefox running on weston

This is a screenshot of firefox running on weston.

Also see http://emilio.pozuelo.org/?p=75
\o/ cheers for that!

Updated

3 years ago
Depends on: 1034064

Updated

3 years ago
No longer depends on: 1034064

Comment 16

2 years ago
Downstream bug - https://bugzilla.redhat.com/show_bug.cgi?id=1054334

Comment 17

2 years ago
Created attachment 8566469 [details] [diff] [review]
shaped patch

Karl, can you please check this one? It uses gtkx.h wrapper to provide a GDK_IS_X11_DISPLAY() macro for GTK2 builds.
Attachment #8445763 - Attachment is obsolete: true
Attachment #8566469 - Flags: feedback?(karlt)
Comment on attachment 8566469 [details] [diff] [review]
shaped patch

>+#include <gtk/gtkx.h>
> 
> #include "gfxImageSurface.h"
> #ifdef MOZ_X11
> #include <gdk/gdkx.h>

GDK_IS_X11_DISPLAY should be provided by <gdk/gdkx.h>, so <gtk/gtkx.h> should
be unnecessary, here at least.

>+++ b/widget/gtk/compat/gtk/gtkx.h
>@@ -0,0 +1,14 @@
>+/* This Source Code Form is subject to the terms of the Mozilla Public
>+ * License, v. 2.0. If a copy of the MPL was not distributed with this
>+ * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
>+
>+#ifndef GTKX_WRAPPER_H
>+#define GTKX_WRAPPER_H
>+
>+#if (MOZ_WIDGET_GTK == 3)
>+#include_next <gtk/gtkx.h>
>+#endif
>+
>+#define GDK_IS_X11_DISPLAY(a)   (true)

widget/gtk/compat/gdk/gdkx.h would be the place to define GDK_IS_X11_DISPLAY.

It should only be defined if not already defined,
or only #if (GTK_MAJOR_VERSION == 2).

>+        bool useXlibSurface = (UseXRender() && !UseImageOffscreenSurfaces());
>+        if (useXlibSurface) {
>+            useXlibSurface = GDK_IS_X11_DISPLAY(gdk_display_get_default());
>+        }

Assume that UseXRender() returning true means the default display is an X11
display.

>+  mGdkDisplay = gdk_display_open(display_name);
>+  if (!mGdkDisplay) {
>+    PR_fprintf(PR_STDERR, "Error: cannot open display: %s\n", display_name);
>+    return 1;
>+  }
>+  gdk_display_manager_set_default_display (gdk_display_manager_get(),
>+                                           mGdkDisplay);    
> #endif /* MOZ_WIDGET_GTK */
> 
> #ifdef MOZ_ENABLE_XREMOTE
>   // handle --remote now that xpcom is fired up
>   bool newInstance;
>   {
>     char *e = PR_GetEnv("MOZ_NO_REMOTE");
>     mDisableRemote = (e && *e);
>+#if defined(MOZ_WIDGET_GTK)
>+    if (!GDK_IS_X11_DISPLAY(mGdkDisplay))
>+      mDisableRemote = true;

XInitThreads() needs to be called before Xlib is used.

I wonder whether it would be tidier to set mDisableRemote in the
MOZ_WIDGET_GTK block above and then use
mDisableRemote = mDisableRemove && e && *e;

>   gdk_window_add_filter(mRootWindow, root_window_event_filter, this);
> #ifdef MOZ_X11
>-  mNetWorkareaAtom =
>-    XInternAtom(GDK_WINDOW_XDISPLAY(mRootWindow), "_NET_WORKAREA", False);
>+  if (GDK_IS_X11_DISPLAY(gdk_display_get_default()))
>+      mNetWorkareaAtom =
>+        XInternAtom(GDK_WINDOW_XDISPLAY(mRootWindow), "_NET_WORKAREA", False);
> #endif

I don't know whether Wayland uses properties like _NET_WORKAREA or whether it
has its own mechanisms.  If it uses this property then GDK has
gdk_atom_intern_static_string() for any backend.
If Wayland uses another mechanism, then initialize mNetWorkareaAtom to
something so that it won't match in root_window_event_filter.

>     if (synthEvent) {
> #ifdef MOZ_X11
>-        event.refPoint.x = nscoord(xevent.xmotion.x);
>-        event.refPoint.y = nscoord(xevent.xmotion.y);
>-
>-        modifierState = xevent.xmotion.state;
>-
>-        event.time = xevent.xmotion.time;
>-#else
>-        event.refPoint.x = nscoord(aEvent->x);
>-        event.refPoint.y = nscoord(aEvent->y);
>-
>-        modifierState = aEvent->state;
>-
>-        event.time = aEvent->time;
>+        if (isX11Display) {
>+            event.refPoint.x = nscoord(xevent.xmotion.x);
>+            event.refPoint.y = nscoord(xevent.xmotion.y);
>+
>+            modifierState = xevent.xmotion.state;
>+
>+            event.time = xevent.xmotion.time;
>+        }
>+        else {
>+#endif /* MOZ_X11 */
>+            event.refPoint.x = nscoord(aEvent->x);
>+            event.refPoint.y = nscoord(aEvent->y);
>+
>+            modifierState = aEvent->state;
>+
>+            event.time = aEvent->time;
>+#ifdef MOZ_X11
>+        }
> #endif /* MOZ_X11 */

synthEvent can only be true when MOZ_X11 is defined and
GDK_IS_X11_DISPLAY(gdk_display_get_default()), so most of this is not needed.
Attachment #8566469 - Flags: feedback?(karlt) → feedback+

Comment 19

2 years ago
Created attachment 8572611 [details] [diff] [review]
wayland v.2

Thanks, there's an updated one. 

Another check added tp nsWindow::HasPendingInputEvent() which was missing in the original patch.

> XInitThreads() needs to be called before Xlib is used.
> 
> I wonder whether it would be tidier to set mDisableRemote in the
> MOZ_WIDGET_GTK block above and then use
> mDisableRemote = mDisableRemove && e && *e;

I see. I think the correct construction is (mDisableRemove || (e && *e)).

> If Wayland uses another mechanism, then initialize mNetWorkareaAtom to
> something so that it won't match in root_window_event_filter.

It does not use _NET_WORKAREA so I initialized it to 0 in class constructor.
Attachment #8566469 - Attachment is obsolete: true
Attachment #8572611 - Flags: review?(karlt)
Comment on attachment 8572611 [details] [diff] [review]
wayland v.2

(In reply to Martin Stránský from comment #19)
> I see. I think the correct construction is (mDisableRemove || (e && *e)).

Ah, yes.  Thank you.

>+  if (!GDK_IS_X11_DISPLAY(mGdkDisplay))
>+    mDisableRemote = true;
>+# endif

Please add {} on this conditional block, which is the style we're moving
towards (though I don't mind missing {} around jump statements such as
return).

And please remove the space in "# endif" so that it aligns with the #if above.

>+STUB(gdk_cairo_create)

I don't see this used outside nptest_gtk2.cpp, where the stub should not be
necessary.

Please remove, or is a preprocessing change causing something to depend on
this?
Attachment #8572611 - Flags: review?(karlt) → review+

Comment 21

2 years ago
Created attachment 8573204 [details] [diff] [review]
wayland for check-in

Thanks, there's the one for check-in. try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=04dd5d53450f

gdk_cairo_create is a leftover from my experiments with nsWindow::GetThebesSurface() which need an update but I'd prefer to leave it to another patch.
Attachment #8572611 - Attachment is obsolete: true

Updated

2 years ago
Whiteboard: [ leave open for more patches ]
Whiteboard: [ leave open for more patches ] → [ leave open for tracking ]
Please file new bugs, blocking this one, for other patches.  A single Bugzilla bug is not good at managing multiple threads, but multiple bugs can organize related information.
Keywords: leave-open

Updated

2 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/53503035a93d
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/53503035a93d

Comment 25

2 years ago
Created attachment 8643709 [details] [diff] [review]
WIP patch

There's a followup patch for non X11 bacekends (tested on broadway and wayland).
I'd like to discuss it here and we can divide it to separate bugs then. It address those issues:

- draw to container window - we can't draw on toplevel window on wayland because it's bigger than the widget and it's used to render widget shadow. So I use mozcontainer window for rendering.
- create gfxSurface (in GetThebesSurface) as a wrapped one. Is there any better way? Off screen surface or something different?
- cairo subsurfaces fixes - non-X11 gtk uses cairo subsurface types which are tricky - reported as images but image backend mostly fails. 
- disables GXL support
- disables OMTC (is it supposed to work somehow on wayland?)
- try to detect propper backend from ENV variables

Thanks!
Attachment #8643709 - Flags: feedback?(karlt)

Comment 26

2 years ago
Just FYI, switching over to GTK+3 seems to be coming soon, see e.g. Bug 1186748.

Comment 27

2 years ago
Sorry, Bug 1186003 is the one. We have GTK+3 in Fx 42+.
(In reply to Martin Stránský from comment #25)
> - disables OMTC (is it supposed to work somehow on wayland?)

What's broken with OMTC? Disabling it isn't going to be an option.
Comment on attachment 8643709 [details] [diff] [review]
WIP patch

(In reply to Martin Stránský from comment #25)
> - draw to container window - we can't draw on toplevel window on wayland
> because it's bigger than the widget and it's used to render widget shadow.
> So I use mozcontainer window for rendering.

This makes sense.  It is more a CSD issue than a Wayland issue.  The issue
exists on X11 also (bug 1195002).  I assume Wayland doesn't force compositors
to depend on clients for decorations.

> - create gfxSurface (in GetThebesSurface) as a wrapped one.

That seems reasonable to me.  I'm not familiar with the drawing model though.
Is a swap-buffers required after drawing?

> - cairo subsurfaces fixes - non-X11 gtk uses cairo subsurface types which
> are tricky - reported as images but image backend mostly fails.

I don't know anything about that.

These things are going to be easier to review in conceptual chunks with
reasoning behind them.  If this is working around a cairo bug, then we need to
consider why this can't be fixed in cairo.  I suspect we have time before
the Wayland port is ready for production.

> - disables GXL support

Haven't really looked at that, but that can be handled separately, I assume.

> - disables OMTC (is it supposed to work somehow on wayland?)

Currently GetThebesSurface() is used on the compositor thread which is an
existing bug because GDK is not designed for multi-thread access.

For OMTC, I guess it is possible to fetch the surface on the main thread and
then return it when requested on the compositor thread.

> - try to detect propper backend from ENV variables

I haven't looked into details there either but that is also an isolated change.
Attachment #8643709 - Flags: feedback?(karlt) → feedback+
Duplicate of this bug: 1190183

Updated

2 years ago
Blocks: 1215078

Updated

2 years ago
Blocks: 1215082

Updated

2 years ago
Blocks: 1215085

Updated

2 years ago
Blocks: 1215088

Updated

2 years ago
Blocks: 1215104
Blocks: 1228424

Comment 31

9 months ago
I tested latest nightly and works fine on Wayland, with patches from Bug 1215085 Bug 1215088 and Bug 1215104. So we need just 3 extra patches to make Firefox work on Wayland.

Comment 32

9 months ago
Created attachment 8763594 [details] [diff] [review]
patch

Complete Wayland patch for latest trunk.
Attachment #8573204 - Attachment is obsolete: true
Attachment #8643709 - Attachment is obsolete: true

Updated

9 months ago
Depends on: 1281425

Comment 33

9 months ago
Archlinux 64bit. With the above patch Firefox is still broken on Wayland+Weston. E.g content in Firefox window is updated only after focusing on another window and focusing back to the Firefox window. Off Main Thread Compositing is disabled.

Comment 34

9 months ago
I created a package which applies the patches to the 47.0 sources: https://aur.archlinux.org/packages/firefox-wayland
Unfortunately this doesn't work yet ... I guess I have apply this patch to trunk?
I started firefox with: GDK_BACKEND=wayland firefox

Comment 35

9 months ago
Working packages are here but that's Fedora builds (wayland by default, EGL enabled):
https://copr.fedorainfracloud.org/coprs/stransky/firefox-wayland

The missing rendering content is caused by enabled OMTC, you need to set:
layers.offmainthreadcomposition.force-disabled:true on trunk.

Updated

9 months ago
Depends on: 1282015

Comment 36

9 months ago
>>Working packages are here but that's Fedora builds (wayland by default, EGL enabled):

Tried these as well, same issue.

>>The missing rendering content is caused by enabled OMTC, you need to set:

OMTC is disabled, also content is not missing but is drawn only on window blur. For example, content is updated after focusing on another window and focusing back to the Firefox window. Also, clicking in the addressbar does not show the cursor, but clicking on the menu and bookmarks icon does show menus.

mozconfig

. $topsrcdir/browser/config/mozconfig

ac_add_options --enable-default-toolkit=cairo-gtk3
ac_add_options --with-system-nspr
ac_add_options --with-system-nss
ac_add_options --enable-system-sqlite
ac_add_options --disable-system-cairo
ac_add_options --enable-system-ffi
ac_add_options --disable-debug
ac_add_options --enable-optimize="-g -O2"
ac_add_options --disable-crashreporter
ac_add_options --disable-tests
ac_add_options --without-system-jpeg
ac_add_options --with-system-libvpx
ac_add_options --with-system-icu
ac_add_options --enable-release
ac_add_options --enable-pie
ac_add_options --with-gl-provider=EGL

export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
export MOZILLA_TELEMETRY=0
mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1

Comment 37

9 months ago
The nightly on Wayland should now work on Archlinux after these steps.

- gfx/thebes/gfxPlatform.cpp - find LayersOffMainThreadCompositionForceDisabled( and add return false; to  the  top of the function. Setting layers.offmainthreadcomposition.force-disabled instead did not work for me.
- Uncheck "Enable multi-process Nightly" in the preferences and restart. Otherwise, not configuration pages will be empty.
- When clicking some icons or items in the menu - e.g Zoom In, you have to hold Ctrl.

Updated

9 months ago
Depends on: 1283055

Updated

9 months ago
No longer blocks: 1215104
Depends on: 1215104

Updated

9 months ago
Depends on: 726479

Comment 38

9 months ago
all y bags when i start firefox-trunk without xwayland

(firefox-trunk:3588): Gtk-WARNING **: Failed to parse 
/home/x/.config/gtk-3.0/se ttings.ini: Key file does not start with a 
group 

(firefox-trunk:3588): Gtk-WARNING **: Failed to parse/home/x/.config/gtk-3.0/se ttings.ini: Key file does not start with a 
group 

(firefox-trunk:3588): GConf-WARNING **: Client failed to connect 
to the D-BUS da emon: Unable to autolaunch a dbus-daemon without a 
$DISPLAY for X11 

(firefox-trunk:3588): GConf-WARNING **: Client failed 
to connect to the D-BUS da emon: Unable to autolaunch a dbus-daemon 
without a $DISPLAY for X11 žÑˆÐ¸Ð±ÐºÐ° сегментирования


 [Child 4679] ###!!! ABORT: Aborting on channel error.: file 
/build/firefox-tru 
nk-_hskEs/firefox-trunk-50.0~a1~hg20160708r304097/ipc/glue/MessageChannel.cpp, 
l ine 2053 


(firefox-trunk:4805): Gtk-WARNING **: Failed to parse 
/home/x/.config/gtk-3.0/se ttings.ini: Key file does not have group 
'Settings'

Comment 39

8 months ago
This isn't directly related to this bug in particular but I have tried running a regular firefox build in a wayland session using Xwayland. Resizing the window causes the black box window to be drawn behind firefox. It disappears when resizing is done.
Can that be fixed? This alone would be a huge usability improvement.

Updated

7 months ago
Depends on: 1299083

Updated

6 months ago
Blocks: 1305341
Priority: -- → P5

Updated

6 months ago
Depends on: 1306613
Comment hidden (spam)

Comment 41

2 months ago
Latest WIP version is at https://github.com/stransky/gecko-dev
Comment hidden (advocacy)
Comment hidden (advocacy)
Comment hidden (advocacy)

Comment 45

2 months ago
@Martin Stránský: Thank you for maintaining this repo! I tried to make a buildscript for the ArchLinux user repository here: https://aur.archlinux.org/packages/firefox-wayland-git

Unfortunately I get a compile error, maybe you know why:
> /usr/bin/g++ -std=gnu++11 -o Unified_cpp_js_src9.o -c  -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/dist/system_wrappers -include /home/onny/projects/firefox-wayland-git/src/gecko-dev/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DENABLE_BINARYDATA -DENABLE_SIMD -DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API -DJS_HAS_CTYPES '-DDLL_PREFIX="lib"' '-DDLL_SUFFIX=".so"' -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/js/src -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/js/src  -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/dist/include  -I/usr/include/nspr        -fPIC  -DMOZILLA_CLIENT -include /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/js/src/js-confdefs.h -MD -MP -MF .deps/Unified_cpp_js_src9.o.pp -D_FORTIFY_SOURCE=2 -O2 -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -fno-delete-null-pointer-checks -fno-schedule-insns2 -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe  -g -freorder-blocks -O3 -fomit-frame-pointer  -I/usr/lib/libffi-3.2.1/include -Wno-shadow -Werror=format  /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/js/src/Unified_cpp_js_src9.cpp
> libjs_static.a
> rm -f libjs_static.a libjs_static.a.desc
> /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python /home/onny/projects/firefox-wayland-git/src/gecko-dev/config/expandlibs_exec.py --extract -- ar crs libjs_static.a RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../config/external/ffi/libconfig_external_ffi.a ../../config/external/icu/libicu.a ../../config/external/fdlibm/libfdlibm.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a 
> make[3]: *** [/home/onny/projects/firefox-wayland-git/src/gecko-dev/config/recurse.mk:33: compile] Error 2
> make[3]: Leaving directory '/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu'
> make[2]: *** [/home/onny/projects/firefox-wayland-git/src/gecko-dev/config/rules.mk:523: default] Error 2
> make[2]: Leaving directory '/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu'
> make[1]: *** [/home/onny/projects/firefox-wayland-git/src/gecko-dev/client.mk:415: realbuild] Error 2
> make[1]: Leaving directory '/home/onny/projects/firefox-wayland-git/src/gecko-dev'
> make: *** [client.mk:170: build] Error 2
> ==> ERROR: A failure occurred in build().
>     Aborting...
It looks like this command is failing:
> Executing: ar crs CTypes.o ConditionVariable.o Disassembler-x86-shared.o ExecutableAllocatorPosix.o Initialization.o Library.o MutexImpl.o Parser.o RegExp.o StoreBuffer.o Thread.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o tmpj6OdrR/e_acos.o tmpj6OdrR/e_acosh.o tmpj6OdrR/e_asin.o tmpj6OdrR/e_atan2.o tmpj6OdrR/e_atanh.o tmpj6OdrR/e_cosh.o tmpj6OdrR/e_exp.o tmpj6OdrR/e_hypot.o tmpj6OdrR/e_log.o tmpj6OdrR/e_log10.o tmpj6OdrR/e_log2.o tmpj6OdrR/e_pow.o tmpj6OdrR/e_sinh.o tmpj6OdrR/e_sqrt.o tmpj6OdrR/k_exp.o tmpj6OdrR/s_asinh.o tmpj6OdrR/s_atan.o tmpj6OdrR/s_cbrt.o tmpj6OdrR/s_ceil.o tmpj6OdrR/s_ceilf.o tmpj6OdrR/s_copysign.o tmpj6OdrR/s_expm1.o tmpj6OdrR/s_fabs.o tmpj6OdrR/s_floor.o tmpj6OdrR/s_floorf.o tmpj6OdrR/s_log1p.o tmpj6OdrR/s_nearbyint.o tmpj6OdrR/s_rint.o tmpj6OdrR/s_rintf.o tmpj6OdrR/s_scalbn.o tmpj6OdrR/s_tanh.o tmpj6OdrR/s_trunc.o tmpj6OdrR/s_truncf.o RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../modules/fdlibm/src/e_acos.o ../../modules/fdlibm/src/e_acosh.o ../../modules/fdlibm/src/e_asin.o ../../modules/fdlibm/src/e_atan2.o ../../modules/fdlibm/src/e_atanh.o ../../modules/fdlibm/src/e_cosh.o ../../modules/fdlibm/src/e_exp.o ../../modules/fdlibm/src/e_hypot.o ../../modules/fdlibm/src/e_log.o ../../modules/fdlibm/src/e_log10.o ../../modules/fdlibm/src/e_log2.o ../../modules/fdlibm/src/e_pow.o ../../modules/fdlibm/src/e_sinh.o ../../modules/fdlibm/src/e_sqrt.o ../../modules/fdlibm/src/k_exp.o ../../modules/fdlibm/src/s_asinh.o ../../modules/fdlibm/src/s_atan.o ../../modules/fdlibm/src/s_cbrt.o ../../modules/fdlibm/src/s_ceil.o ../../modules/fdlibm/src/s_ceilf.o ../../modules/fdlibm/src/s_copysign.o ../../modules/fdlibm/src/s_expm1.o ../../modules/fdlibm/src/s_fabs.o ../../modules/fdlibm/src/s_floor.o ../../modules/fdlibm/src/s_floorf.o ../../modules/fdlibm/src/s_log1p.o ../../modules/fdlibm/src/s_nearbyint.o ../../modules/fdlibm/src/s_rint.o ../../modules/fdlibm/src/s_rintf.o ../../modules/fdlibm/src/s_scalbn.o ../../modules/fdlibm/src/s_tanh.o ../../modules/fdlibm/src/s_trunc.o ../../modules/fdlibm/src/s_truncf.o
> ar: CTypes.o: File format not recognized
I would really appreciate any hint :)
Thanks!

Comment 46

2 months ago
Further ...
> % file CTypes.o                                                                :(
> CTypes.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

Comment 47

2 months ago
Following files doesn't seem to exists:
>  ../../config/external/ffi/libconfig_external_ffi.a ../../config/external/icu/libicu.a ../../config/external/fdlibm/libfdlibm.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a 
So this command works fine
> ar crs libjs_static.a RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o
Where as this command, from the build script, fails
> % /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python /home/onny/projects/firefox-wayland-git/src/gecko-dev/config/expandlibs_exec.py --extract -- ar crs libjs_static.a RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../config/external/ffi/libconfig_external_ffi.a ../../config/external/icu/libicu.a ../../config/external/fdlibm/libfdlibm.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a
> Executing: ar crs CTypes.o ConditionVariable.o Disassembler-x86-shared.o ExecutableAllocatorPosix.o Initialization.o Library.o MutexImpl.o Parser.o RegExp.o StoreBuffer.o Thread.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o tmpRC5Q8O/e_acos.o tmpRC5Q8O/e_acosh.o tmpRC5Q8O/e_asin.o tmpRC5Q8O/e_atan2.o tmpRC5Q8O/e_atanh.o tmpRC5Q8O/e_cosh.o tmpRC5Q8O/e_exp.o tmpRC5Q8O/e_hypot.o tmpRC5Q8O/e_log.o tmpRC5Q8O/e_log10.o tmpRC5Q8O/e_log2.o tmpRC5Q8O/e_pow.o tmpRC5Q8O/e_sinh.o tmpRC5Q8O/e_sqrt.o tmpRC5Q8O/k_exp.o tmpRC5Q8O/s_asinh.o tmpRC5Q8O/s_atan.o tmpRC5Q8O/s_cbrt.o tmpRC5Q8O/s_ceil.o tmpRC5Q8O/s_ceilf.o tmpRC5Q8O/s_copysign.o tmpRC5Q8O/s_expm1.o tmpRC5Q8O/s_fabs.o tmpRC5Q8O/s_floor.o tmpRC5Q8O/s_floorf.o tmpRC5Q8O/s_log1p.o tmpRC5Q8O/s_nearbyint.o tmpRC5Q8O/s_rint.o tmpRC5Q8O/s_rintf.o tmpRC5Q8O/s_scalbn.o tmpRC5Q8O/s_tanh.o tmpRC5Q8O/s_trunc.o tmpRC5Q8O/s_truncf.o RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../modules/fdlibm/src/e_acos.o ../../modules/fdlibm/src/e_acosh.o ../../modules/fdlibm/src/e_asin.o ../../modules/fdlibm/src/e_atan2.o ../../modules/fdlibm/src/e_atanh.o ../../modules/fdlibm/src/e_cosh.o ../../modules/fdlibm/src/e_exp.o ../../modules/fdlibm/src/e_hypot.o ../../modules/fdlibm/src/e_log.o ../../modules/fdlibm/src/e_log10.o ../../modules/fdlibm/src/e_log2.o ../../modules/fdlibm/src/e_pow.o ../../modules/fdlibm/src/e_sinh.o ../../modules/fdlibm/src/e_sqrt.o ../../modules/fdlibm/src/k_exp.o ../../modules/fdlibm/src/s_asinh.o ../../modules/fdlibm/src/s_atan.o ../../modules/fdlibm/src/s_cbrt.o ../../modules/fdlibm/src/s_ceil.o ../../modules/fdlibm/src/s_ceilf.o ../../modules/fdlibm/src/s_copysign.o ../../modules/fdlibm/src/s_expm1.o ../../modules/fdlibm/src/s_fabs.o ../../modules/fdlibm/src/s_floor.o ../../modules/fdlibm/src/s_floorf.o ../../modules/fdlibm/src/s_log1p.o ../../modules/fdlibm/src/s_nearbyint.o ../../modules/fdlibm/src/s_rint.o ../../modules/fdlibm/src/s_rintf.o ../../modules/fdlibm/src/s_scalbn.o ../../modules/fdlibm/src/s_tanh.o ../../modules/fdlibm/src/s_trunc.o ../../modules/fdlibm/src/s_truncf.o
> ar: CTypes.o: File format not recognized
Comment hidden (advocacy)
Comment hidden (offtopic)
This is slightly out-of-topic.  Martin Stránský, could you rebase your repo to https://hg.mozilla.org/mozilla-central/rev/ebcbf47a83e7 or backport this changeset? That fixes building on Arch Linux (partially).
Comment hidden (advocacy)

Updated

2 months ago
Summary: Make Firefox work as well with Wayland (without X) as with just X → Firefox Wayland port

Updated

2 months ago
Depends on: 1336047

Updated

2 months ago
Depends on: 1336048

Updated

2 months ago
Depends on: 1336071

Updated

2 months ago
Depends on: 1337369

Updated

2 months ago
Duplicate of this bug: 1332857

Comment 53

a month ago
I created a Flatpak of @stranskys Firefox Wayland version, so it is easy to try out on all x64 Linux systems without having to compile it https://project-insanity.org/blog/2017/02/14/try-out-firefox-on-wayland-easily/

Updated

a month ago
Depends on: 1339916

Updated

a month ago
Depends on: 1339917

Updated

a month ago
Depends on: 1339920

Updated

10 days ago
Depends on: 1345666

Updated

8 days ago
Depends on: 1348310
You need to log in before you can comment on or make changes to this bug.