Created attachment 259442 [details] complete build log (xz compressed, 68M uncompressed) In webkit-gtk-2.8.5 and 2.8.4, I am seeing an interesting failure when trying to build with -DENABLE_API_TESTS=ON: [5414/5418] : && /usr/bin/x86_64-pc-linux-gnu-g++ -march=native -O2 -pipe -ggdb -frecord-gcc-switches -fstack-protector-strong -fno-strict-aliasing -std=c++11 -Wl,--as-needed -Wl,-O1 -Wl,--no-keep-memory -fuse-ld=gold -Wl,--disable-new-dtags @CMakeFiles/TestWebKit2.rsp -o bin/TestWebKitAPI/WebKit2/TestWebKit2 && : FAILED: : && /usr/bin/x86_64-pc-linux-gnu-g++ -march=native -O2 -pipe -ggdb -frecord-gcc-switches -fstack-protector-strong -fno-strict-aliasing -std=c++11 -Wl,--as-needed -Wl,-O1 -Wl,--no-keep-memory -fuse-ld=gold -Wl,--disable-new-dtags @CMakeFiles/TestWebKit2.rsp -o bin/TestWebKitAPI/WebKit2/TestWebKit2 && : /var/tmp2/portage/net-libs/webkit-gtk-2.8.5/work/webkitgtk-2.8.5/Tools/TestWebKitAPI/Tests/WebKit2/AboutBlankLoad.cpp:46: error: undefined reference to 'WKContextCreate' /var/tmp2/portage/net-libs/webkit-gtk-2.8.5/work/webkitgtk-2.8.5/Tools/TestWebKitAPI/Tests/WebKit2/AboutBlankLoad.cpp:55: error: undefined reference to 'WKPageSetPageLoaderClient' /var/tmp2/portage/net-libs/webkit-gtk-2.8.5/work/webkitgtk-2.8.5/Tools/TestWebKitAPI/Tests/WebKit2/AboutBlankLoad.cpp:57: error: undefined reference to 'WKURLCreateWithUTF8CString' /var/tmp2/portage/net-libs/webkit-gtk-2.8.5/work/webkitgtk-2.8.5/Tools/TestWebKitAPI/Tests/WebKit2/AboutBlankLoad.cpp:57: error: undefined reference to 'WKPageLoadURL' [...250 similar lines omitted here...] /var/tmp2/portage/net-libs/webkit-gtk-2.8.5/work/webkitgtk-2.8.5/Tools/TestWebKitAPI/PlatformUtilities.cpp:51: error: undefined reference to 'WKDictionarySetItem' /var/tmp2/portage/net-libs/webkit-gtk-2.8.5/work/webkitgtk-2.8.5/Tools/TestWebKitAPI/PlatformUtilities.cpp:54: error: undefined reference to 'WKDictionarySetItem' /var/tmp2/portage/net-libs/webkit-gtk-2.8.5/work/webkitgtk-2.8.5/Tools/TestWebKitAPI/PlatformUtilities.cpp:64: error: undefined reference to 'WKContextSetInitializationUserDataForInjectedBundle' /var/tmp2/portage/net-libs/webkit-gtk-2.8.5/work/webkitgtk-2.8.5/Tools/TestWebKitAPI/PlatformUtilities.cpp:71: error: undefined reference to 'WKStringGetMaximumUTF8CStringSize' /var/tmp2/portage/net-libs/webkit-gtk-2.8.5/work/webkitgtk-2.8.5/Tools/TestWebKitAPI/PlatformUtilities.cpp:73: error: undefined reference to 'WKStringGetUTF8CString' collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. It seems that for some reason, the linker is failing to find lib/libwebkit2gtk-4.0.so.37.6.8 even though lib/libwebkit2gtk-4.0.so.37.6.8 was already built (tested using ninja -j 1) and was listed in CMakeFiles/TestWebKit2.rsp: -rdynamic lib/libTestWebKitAPIBase.a lib/libWTFGTK.a lib/libwebkit2gtk-4.0.so.37.6.8 lib/libgtest.so -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgobject-2.0 -lglib-2.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -Wl,--whole-archive -Wl,--no-whole-archive lib/libWebCoreGTK.a -lgnutls lib/libANGLESupport.a -lrt lib/libGObjectDOMBindings.a lib/libWebCorePlatformGTK.a lib/libjavascriptcoregtk-4.0.so.18.1.12 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lGL -lEGL -latk-1.0 -lcairo -lenchant -lfontconfig -lfreetype -lgmodule-2.0 -lharfbuzz -lharfbuzz-icu -ljpeg -lsecret-1 -lsoup-2.4 -lxml2 -lxslt -lpng -lsqlite3 -lwebp -lX11 -lXcomposite -lXdamage -lXrender -lXt -lgstapp-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgstpbutils-1.0 -lgstaudio-1.0 -lgsttag-1.0 -lgstvideo-1.0 -lgstmpegts-1.0 -lgstfft-1.0 -lnotify -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 lib/libWTFGTK.a -ldl lib/libbmalloc.a -licui18n -licuuc -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lpthread -lz -lpthread -Wl,-rpath,/var/tmp2/portage/net-libs/webkit-gtk-2.8.5/work/webkit-gtk-2.8.5_build/lib
Created attachment 463858 [details] build.log (38M uncompressed) I still see similar looking errors on 2.38.2 (and all prior versions since I've been packaging this in Gentoo for the last few years) /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: InjectedBundleController.cpp:(.text+0x725): undefined reference to `WKRelease' /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: InjectedBundleController.cpp:(.text+0x784): undefined reference to `WKBundleSetClient' /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: InjectedBundleController.cpp:(.text+0x790): undefined reference to `WKStringCreateWithUTF8CString' /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: InjectedBundleController.cpp:(.text+0x79e): undefined reference to `WKDictionaryGetItemForKey' /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: InjectedBundleController.cpp:(.text+0x7ad): undefined reference to `WKStringCreateWithUTF8CString' /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: InjectedBundleController.cpp:(.text+0x7bb): undefined reference to `WKDictionaryGetItemForKey' /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: InjectedBundleController.cpp:(.text+0x810): undefined reference to `WKRelease'
Michael: do you have any ideas about this?
Hmmm, you're trying to use -DENABLE_API_TESTS=ON from a release tarball, right? That's not going to work without some effort. The tests depend on internal symbols that are stripped out by the linker version script. This means we need to change how WebKit is linked yet again, and that's always pretty scary. We'd need static builds of libjsc and libwebkit. Won't be fun.
I don't have any ideas how valuable the unit tests are for Gentoo testers to execute. If you don't think that's a worthwhile goal, I'm fine with it going unfixed.
It's definitely a worthwhile goal, just not something that's going to be easy. Let me retitle this bug to reflect the broader scope of the problem. (I'm sure we have a duplicate bug report for this somewhere, but not sure where.)
I found bug #215986 for enabling the API tests in tarball builds. Let's track that problem in that bug. I've retitled this bug back to its original title. Now, I think the problem here is you've attempted to build with -DENABLE_API_TESTS=ON. But this is a private build flag and it's not going to work from tarball builds. It's expected that WebKit will fail to build if you modify private flags anyway, so I'm going to close this.