RESOLVED INVALID251212
[GTK] compile errors in derived source WebKitEnumTypes.cpp 
https://bugs.webkit.org/show_bug.cgi?id=251212
Summary [GTK] compile errors in derived source WebKitEnumTypes.cpp
Jim Mason
Reported 2023-01-26 08:39:43 PST
Building on Solaris with: -DUSE_GTK4=OFF -DUSE_SOUP2=ON Since some weeks now on main, I've been getting compile errors in a derived source file, WebKitEnumTypes.cpp. I've pasted the errors below. There are two errors: 1) the function `webkit_website_data_types_get_type` is declared twice, and 2) an undefined constant WEBKIT_MEDIA_ERROR_WILL_HANDLE_LOAD is referenced. The errors started sometime after 257698@main but before 258874@main. By manually fixing up WebKitEnumTypes.{h,cpp}, compiling continues and the build seems to run fine. However, I would like to determine the root cause. It seems perhaps related to changes around ENABLE_2022_GLIB_API, which in my case is OFF due to gtk3/libsoup2. Can someone please suggest something to check, and I will try. The errors are these: /build/rtutils/components/desktop/webkitgtk4-dev/build/amd64/WebKitGTK/DerivedSources/webkit/WebKitEnumTypes.cpp: At global scope: /build/rtutils/components/desktop/webkitgtk4-dev/build/amd64/WebKitGTK/DerivedSources/webkit/WebKitEnumTypes.cpp:770:7: error: redefinition of 'GType webkit_website_data_types_get_type()' 770 | GType webkit_website_data_types_get_type() | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /build/rtutils/components/desktop/webkitgtk4-dev/build/amd64/WebKitGTK/DerivedSources/webkit/WebKitEnumTypes.cpp:745:7: note: 'GType webkit_website_data_types_get_type()' previously defined here 745 | GType webkit_website_data_types_get_type() | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and /build/rtutils/components/desktop/webkitgtk4-dev/build/amd64/WebKitGTK/DerivedSources/webkit/WebKitEnumTypes.cpp: In function 'GType webkit_media_error_get_type()': /build/rtutils/components/desktop/webkitgtk4-dev/build/amd64/WebKitGTK/DerivedSources/webkit/WebKitEnumTypes.cpp:321:11: error: 'WEBKIT_MEDIA_ERROR_WILL_HANDLE_LOAD' was not declared in this scope; did you mean 'WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD'? 321 | { WEBKIT_MEDIA_ERROR_WILL_HANDLE_LOAD, "WEBKIT_MEDIA_ERROR_WILL_HANDLE_LOAD", "load" }, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD
Attachments
Add attachment proposed patch, testcase, etc.
Michael Catanzaro
Comment 1 2023-01-26 10:00:46 PST
Did you try a clean build? The only way this could happen is if (a) it's processing WebKitError.h.in instead of WebKitError.h, but I see we only pass headers that are actually installed to glib-mkenums, so that shouldn't be possible, or (b) you perhaps reused the same build directory after building the GTK 4 API version? The WEBKIT_MEDIA_ERROR_WILL_HANDLE_LOAD is only declared in one place so that's a dead giveaway that your supposedly GTK 3 build is processing GTK 4 stuff.
Michael Catanzaro
Comment 2 2023-01-26 10:01:21 PST
Also I'm quite impressed you got WebKitGTK working on Solaris. Good job. ;)
Jim Mason
Comment 3 2023-01-27 02:51:53 PST
Thanks for the prompt feedback, Michael. > Did you try a clean build? > The only way this could happen is if (a) it's processing WebKitError.h.in > instead of WebKitError.h, but I see we only pass headers that are actually This information helped me find the root cause: There was a stale component `unifdef` in my build chain. As a result, enums that were supposed to be guarded by ENABLE_2022_GLIB_API made their way into the source. Updating `unifdef` resolved the issue. As problem is specific to my build environment, I am closing as invalid. > Also I'm quite impressed you got WebKitGTK working on Solaris. Good job. ;) Thanks, I've been publishing Solaris-specific patch sets for every stable release since 2018. https://github.com/RocketMan/solaris-ports/tree/master/components/desktop/webkitgtk4 2.38.3 is the best release yet. Thanks to you and the Igalia developers for making it happen! I use it daily in epiphany 42.4 on Solaris as my primary browser (from which I am posting this, in fact). I also build from main to stay on top of forthcoming changes. Main is looking great with WebGL2 and, for me on Solaris at least, sound is finally working in the WebAssembly tanks demo.
Note You need to log in before you can comment on or make changes to this bug.