Bug 166492 – [GTK] WebCore/CSSParser unit test is not being built

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Manuel Rego Casasnovas]

This test was introduced in bug #136217 (r175930).
https://trac.webkit.org/changeset/r175930

But just the day after, as it was causing issues to build GTK+ port the unit test was removed from the CMake file so it's not build anymore since then (r176015).
https://trac.webkit.org/changeset/176015

[Manuel Rego Casasnovas]

We should build this test in GTK+ too, but something like this is not enough:
diff --git a/Tools/TestWebKitAPI/PlatformGTK.cmake b/Tools/TestWebKitAPI/PlatformGTK.cmake
index 639d197c070..0bb8cdb4ac9 100644
--- a/Tools/TestWebKitAPI/PlatformGTK.cmake
+++ b/Tools/TestWebKitAPI/PlatformGTK.cmake
@@ -129,6 +129,7 @@ set_target_properties(TestWebKit2 PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${TESTWEBK
 add_executable(TestWebCore
     ${test_main_SOURCES}
     ${TESTWEBKITAPI_DIR}/TestsController.cpp
+    ${TESTWEBKITAPI_DIR}/Tests/WebCore/CSSParser.cpp
     ${TESTWEBKITAPI_DIR}/Tests/WebCore/FileSystem.cpp
     ${TESTWEBKITAPI_DIR}/Tests/WebCore/HTMLParserIdioms.cpp
     ${TESTWEBKITAPI_DIR}/Tests/WebCore/LayoutUnit.cpp

I'm getting some linking errors: http://sprunge.us/gBeQ

[Manuel Rego Casasnovas]

Created attachment 297800 [details]
Patch

[Carlos Garcia Campos]

Comment on attachment 297800 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=297800&action=review

> Tools/TestWebKitAPI/PlatformGTK.cmake:56
> +    WebKit2

Why do you need to link to WebKit2 for WebCore tests? I know you need this to avoid the linking issues you mentioned, but the thing is why you get linking issues.

[Manuel Rego Casasnovas]

Comment on attachment 297800 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=297800&action=review

>> Tools/TestWebKitAPI/PlatformGTK.cmake:56
>> +    WebKit2
> 
> Why do you need to link to WebKit2 for WebCore tests? I know you need this to avoid the linking issues you mentioned, but the thing is why you get linking issues.

This was the way to fix the linking error, but I'm not sure where is the real problem.

I see that if we call the following method we got the linking error:
  RuntimeEnabledFeatures& RuntimeEnabledFeatures::sharedFeatures()
  {
      static NeverDestroyed<RuntimeEnabledFeatures> runtimeEnabledFeatures;

      return runtimeEnabledFeatures;
  }

Any idea is welcomed. :-)

[Michael Catanzaro]

Comment on attachment 297800 [details]
Patch

Like Carlos says, this is a layering violation. All the missing symbols are in WebCore anyway, so linking to WebKit2 doesn't make sense; that's only fixing the problem because WebKit2 happens to link to the missing library. We need to figure out what's really wrong.

Try linking to WebCore in addition to WebCorePlatformGTK, does that fix it?

[Manuel Rego Casasnovas]

(In reply to comment #5)
> Try linking to WebCore in addition to WebCorePlatformGTK, does that fix it?

No, I already tried that.

Let's see if I manage to find what's going on...

[Manuel Rego Casasnovas]

Created attachment 297891 [details]
Patch

[Manuel Rego Casasnovas]

It seems the issue is also fixed if we use "ADD_WHOLE_ARCHIVE_TO_LIBRARIES".

What do you think about this approach?

[Michael Catanzaro]

Comment on attachment 297891 [details]
Patch

Yeah this looks better!

[WebKit Commit Bot]

Comment on attachment 297891 [details]
Patch

Clearing flags on attachment: 297891

Committed r210225: <http://trac.webkit.org/changeset/210225>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.