Building swift-frontend and swift-driver on OSX without separate dlls

Development Compiler
1

Hiya,

In the past when I've built swift-frontend etc with build-script, it has built a large, monolithic compiler with no dll dependencies except platform dlls (libSystem etc.) so it can easily be deployed to other machines.

With the most recent versions of the compiler (6.2 or so), it's now building the swift driver swift-driver as well as the main swift-frontend and it seems like swift-driver (at least), now depends on a load of DLLs that are compiled locally, meaning it won't run unless I find all of these and move them around.

Looking at otool -l there are load commands even in swift-frontend...

Load command 17
          cmd LC_LOAD_DYLIB
      cmdsize 88
         name @rpath/lib_CompilerSwiftCompilerPluginMessageHandling.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 0.0.0
compatibility version 0.0.0

This is fairly tedious for me (Mac App Store code signing issues). Does it have to be this way? Is there a switch on utils/build-script to disable this and link these parts back into the compiler as before, so I can just deploy one binary, like I used to? I've got to code sign and deploy all these parts...

I'm happy to use ccmake or tinker with CMakefiles if I have to.

Thanks for any help or advice!

Regards,
Carl

2

I thought I'd give an update on this to break radio silence. :slight_smile:

I managed to make a small amount of progress. First, to be clearer what I'm trying to do. Before about Swift 6, the swift compiler swift, swiftc and later swift-frontend used to be "standalone" MacOS executables when I built them, that is, the only dylibs they needed were standard platform (e.g. libSystem.B etc.)

So once they were code signed, I could deploy them in my IDE as standalone command line tools without dependencies.

Some time around Swift 6, with the move to swift in the compiler and the swift-driver driver, the executable started to be linked against a lot of shared dylibs from swift syntax, etc. This makes it hard to deploy. The executables have load commands linking these dlls with a path relative to rpath and a couple of rpath entries that reference directories in the tree next to the executable.

This makes code signing difficult for Mac App Store apps, among other issues, so I'd strongly prefer to avoid it.

After some reading about CMake and experimenting, I worked out that I could tell CMake to link to the static libraries for at least the swift syntax dependencies, using this patch...

diff --git a/lib/CompilerSwiftSyntax/CMakeLists.txt b/lib/CompilerSwiftSyntax/CMakeLists.txt
index 849cf90fee0..7e6755a67c5 100644
--- a/lib/CompilerSwiftSyntax/CMakeLists.txt
+++ b/lib/CompilerSwiftSyntax/CMakeLists.txt
@@ -9,7 +9,7 @@ endif()
 # Build swift-syntax libraries with FetchContent.
 function(includeSwiftSyntax)
   set(CMAKE_Swift_COMPILER_TARGET ${SWIFT_HOST_TRIPLE})
-  set(BUILD_SHARED_LIBS ON)
+  set(BUILD_SHARED_LIBS OFF)
   set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${SWIFT_HOST_LIBRARIES_DEST_DIR}/compiler")
   set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${SWIFT_HOST_LIBRARIES_DEST_DIR}/compiler")
   if(SWIFT_HOST_VARIANT_SDK MATCHES "LINUX|ANDROID|OPENBSD|FREEBSD")

...now at least my swift-frontend is "standalone" in the way I want (it can be used as a MacOS command line tool without non platform dylib dependencies).

swift-driver still has dependencies.

As an emergency backstop, if I can't get swift-driver linking the way I want, I think I can probably use install_name_tool to change the RPATH load command in the built swift-driver to point to @executable_path/. so I can at least deploy the swift format dylibs in the MacOS folder in my XPC service and code sign them (as Mac App Store code signing requires).

But it isn't ideal. Anyway, I think I've made some progress at least! HTH