Bug 305785 – [GTK] Failed to build the Swift demo URI scheme

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

[Alberto Garcia]

Created attachment 478072 [details]
Patch

Hi, when trying to build WebKitGTK (commit b1d17224788592b0e9352be9ec57ea02136640bd) using -DENABLE_SWIFT_DEMO_URI_SCHEME=ON on Debian sid I get these two errors:

/tmp/WebKit/Source/WebKit/Modules/Internal/WebKitInternalCxx.h:28:9: note: in file included from /tmp/WebKit/Source/WebKit/Modules/Internal/WebKitInternalCxx.h:28:
26 | // Add project-level C++ header files here to be able to access them from within Swift sources.
27 |
28 | #import "IPCTesterReceiverMessages.h"
   |         `- note: in file included from /tmp/WebKit/Source/WebKit/Modules/Internal/WebKitInternalCxx.h:28:
29 | #import "UIProcess/SwiftDemoLogoConfirmation.h"
30 |

/tmp/WebKit/build-gtk3/DerivedSources/WebKit/IPCTesterReceiverMessages.h:27:5: error: function-like macro 'ENABLE' is not defined
 25 | #pragma once
 26 |
 27 | #if ENABLE(IPC_TESTING_API)
    |     `- error: function-like macro 'ENABLE' is not defined
 28 |
 29 | #include "ArgumentCoders.h"

/tmp/WebKit/Source/WebKit/UIProcess/SwiftDemoLogo.swift:27:17: error: could not build C module 'WebKit_Internal'
 25 |
 26 | import Foundation
 27 | internal import WebKit_Internal
    |                 `- error: could not build C module 'WebKit_Internal'
 28 |
 29 | extension Data {


I worked around this with the following change:

--- webkitgtk.orig/Source/WebKit/Modules/Internal/WebKitInternalCxx.h
+++ webkitgtk/Source/WebKit/Modules/Internal/WebKitInternalCxx.h
@@ -25,5 +25,6 @@
 
 // Add project-level C++ header files here to be able to access them from within Swift sources.
 
+#import "wtf/Platform.h"
 #import "IPCTesterReceiverSwiftMessages.h"
 #import "UIProcess/SwiftDemoLogoConfirmation.h"



 -------------------------

The only problem is that some of the compiler options are rejected by swiftc so I think the swiftc-wrapper.sh script should filter them.

I'm attaching a patch for both issues.

[Alberto Garcia]

> The only problem is that some of the compiler options are rejected by swiftc

I meant the **other** problem

[Michael Catanzaro]

You noted in Matrix that the Swift runtime uses unversioned shared libraries, which is not acceptable:

```
$ ldd /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser |grep -i swift
	libswiftCore.so => /usr/libexec/swift/lib/swift/linux/libswiftCore.so (0x00007f1e54600000)
	libswift_Concurrency.so => /usr/libexec/swift/lib/swift/linux/libswift_Concurrency.so (0x00007f1e550f6000)
	libswift_StringProcessing.so => /usr/libexec/swift/lib/swift/linux/libswift_StringProcessing.so (0x00007f1e5503a000)
	libswift_RegexParser.so => /usr/libexec/swift/lib/swift/linux/libswift_RegexParser.so (0x00007f1e54ce7000)
	libswiftGlibc.so => /usr/libexec/swift/lib/swift/linux/libswiftGlibc.so (0x00007f1e56bdd000)
	libBlocksRuntime.so => /usr/libexec/swift/lib/swift/linux/libBlocksRuntime.so (0x00007f1e56ffa000)
	libdispatch.so => /usr/libexec/swift/lib/swift/linux/libdispatch.so (0x00007f1e545a1000)
	libswiftDispatch.so => /usr/libexec/swift/lib/swift/linux/libswiftDispatch.so (0x00007f1e55497000)
	libFoundation.so => /usr/libexec/swift/lib/swift/linux/libFoundation.so (0x00007f1e53e00000)
	libFoundationEssentials.so => /usr/libexec/swift/lib/swift/linux/libFoundationEssentials.so (0x00007f1e53600000)
	libFoundationInternationalization.so => /usr/libexec/swift/lib/swift/linux/libFoundationInternationalization.so (0x00007f1e53417000)
	lib_FoundationICU.so => /usr/libexec/swift/lib/swift/linux/lib_FoundationICU.so (0x00007f1e4f400000)
	libswiftSynchronization.so => /usr/libexec/swift/lib/swift/linux/libswiftSynchronization.so (0x00007f1e527ee000)
```

Adrian suggested that we use `-Xswiftc -static-stdlib` to link these runtimes statically instead.

[Michael Catanzaro]

(That was suggested by Adrian Perez, not Adrian Taylor.)

[Alberto Garcia]

My first attempt to use -static-stdlib results in lots of errors like this one:

/usr/libexec/swift/lib/swift_static/shims/module.modulemap:26:8: error: redefinition of module '_SwiftConcurrencyShims'
24 | }
25 | 
26 | module _SwiftConcurrencyShims {
   |        `- error: redefinition of module '_SwiftConcurrencyShims'
27 |   header "_SwiftConcurrency.h"
28 | }

I think the better fix for the Messages.h ENABLE problem is to get messages.py to emit #include <wtf/PlatformEnable.h> (or similar) before it adds a condition. I've got a commit somewhere which does that - I'll try to turn it into a PR.

As to the static/dynamic/versioning issue, could I suggest you add a comment to https://github.com/swiftlang/swift-corelibs-foundation/issues/4456 with your perspectives and needs, and then I'll try to nudge some folks to take a look? (I'm not sure if that's the canonical issue, it's just the one I found through searching).

https://github.com/WebKit/WebKit/pull/56906 for the ENABLE issue.

[Michael Catanzaro]

I have left a comment in that upstream issue.

[Alberto Garcia]

Created attachment 478088 [details]
Error messages when building with -static-stdlib

For reference here's the full error that I get when I use -static-stdlib. I'm adding that flag to the swiftc-wrapper.sh script, that's why you don't see it in the output.

[Alberto Garcia]

Created attachment 478126 [details]
Patch for swiftc-wrapper.sh

Here's the patch that I used for swiftc-wrapper.sh

I have been able to build WebKitGTK on Debian with it.

I also updated the script to set REAL_SWIFTC=swiftc by default. This is optional but I think that it makes sense. It can still be overridden with --original-swift-compiler.

[Alberto Garcia]

Pull request: https://github.com/WebKit/WebKit/pull/60628

[EWS]

Committed 309313@main (76fd1a827851): <https://commits.webkit.org/309313@main>

Reviewed commits have been landed. Closing PR #60628 and removing active labels.