Summary: | [GTK] [2.45.91] Fails to build in armhf: expected identifier before numeric constant | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alberto Garcia <berto> | ||||
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | NEW --- | ||||||
Severity: | Normal | CC: | bugs-noreply, cgarcia, dpino, mcatanzaro | ||||
Priority: | P2 | ||||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Alberto Garcia
2024-08-29 07:46:39 PDT
FWIW I can work around this by using the system malloc in this build. Disabling bmalloc seems to be causing problems on armhf, see bug 279883 I managed to fix the build by changing the order of the Xlib.h include, but I still haven't checked why other architectures are not affected: --- a/Source/WebKit/UIProcess/gtk/PointerLockManagerX11.cpp +++ b/Source/WebKit/UIProcess/gtk/PointerLockManagerX11.cpp @@ -29,10 +29,10 @@ #if PLATFORM(X11) #include "WebPageProxy.h" -#include <X11/Xlib.h> #include <gtk/gtk.h> #include <wtf/TZoneMallocInlines.h> #include <wtf/glib/GRefPtr.h> +#include <X11/Xlib.h> #if USE(GTK4) #include <gdk/x11/gdkx.h> And this is almost certainly the commit that introduced this build failure: https://commits.webkit.org/282294@main (the changes to PointerLockManagerX11.cpp) This a common error that happens when a header defining 'Success' collides with 'Xlib.h', which includes 'X11/X.h' which defines Success. One way of solving is undefining 'Success' before including 'Xlib.h': ``` #ifdef Success #undef Success #endif ``` Another way of solving it is by adding the .c source file that triggers the inclusion of headers until the collide happens as no-unify. In this case, the file would be 'UIProcess/gtk/PointerLockManagerX11.cpp', but that file is already marked as no-unify: https://github.com/webkit/webkit/blob/main/Source/WebKit/SourcesGTK.txt#L283, so this solution won't work in your case. It seems that right now there's no code in WebKit codebase that uses the former solution (undefining Success). So, if rearranging the order of the header fixes the issue I would go for that solution. Perhaps adding a comment explaining why 'Xlib.h' has to go after 'TZoneMallocInlines.h'. Created attachment 473016 [details]
Patch
FYI this is the patch that I'm using downstream in Debian, I don't have time to create a merge request right now but feel free to take this patch if you think it's appropriate.
|