Dynamic library support on Linux with library evolution

[hassila]

Description

Background

We have an enterprise-style application where we have a large number of libraries (swift packages) that we'd like to be able to evolve independently using library evolution and to dynamically link them to a large number of consumers.

Basically adding binary dependency support to a dynamic library generated using SPM similar to XCFrameworks.

I've read https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md and would like to suggest a first step could be to cater to this kind of 'enterprise' deployment scenario rather than taking on the full 'many linuxes support everywhere' - we have full control over deployment operating system and swift toolchain (we can mandate for our customers what they must have to run the software and would do builds for a small number of deployment environments that we support).

The artefact bundle format seems that it would suffice for such a scenario.

So trying to break down what's needed (perhaps missing something):

• Support for binary dependencies also for Linux (preferably using artifactbundle format so we can have both macOS and Linux in a single dependency if putting things in the right places)
• Support for enabling library evolution for SPM packages generating dynamic libraries on both macOS and Linux (accepting the requirement for same toolchain on Linux)

I think this single-linux-distribution as a first step could be very useful not only for us, but also for others - and help as a stopgap deployment measure.

See also related discussions / issues:

swiftlang/swift#60458
https://forums.swift.org/t/use-a-dynamic-library-in-a-swift-package-on-linux/59510
https://forums.swift.org/t/availability-when-using-library-evolution-resilience-for-third-party-libraries/59341/3
etc.

Also recently added:

swiftlang/swift#66156

Expected behavior

No response

Actual behavior

No response

Steps to reproduce

No response

Swift Package Manager version/commit hash

No response

Swift & OS version (output of swift --version && uname -a)

No response

[neonichu]

• Support for binary dependencies also for Linux (preferably using artifactbundle format so we can have both macOS and Linux in a single dependency if putting things in the right places)
• Support for enabling library evolution for SPM packages generating dynamic libraries on both macOS and Linux (accepting the requirement for same toolchain on Linux)

I think this couples a lot of different topics together that should be separate:

• Support for binary dependencies for non-Darwin platforms
• Darwin platform binary dependencies in artifact bundles (personally, I think that's a non-goal since we already have XCFrameworks)
• Library evolution for non-Darwin platforms (this isn't even really a SwiftPM topic)
• Building a binary dependency from a package (I think it might also be a non-goal to do this in SwiftPM for Darwin platforms, because we don't really support building for anything but macOS and even there support is limited, e.g. in terms of resource types)

Only the first one is really needed for the main topic of this particular issue, right?

[hassila]

Hi Boris,

Thanks for trying to split this up,

Support for binary dependencies also for Linux (preferably using artifactbundle format so we can have both macOS and Linux in a single dependency if putting things in the right places)
Support for enabling library evolution for SPM packages generating dynamic libraries on both macOS and Linux (accepting the requirement for same toolchain on Linux)
I think this couples a lot of different topics together that should be separate:

Support for binary dependencies for non-Darwin platforms

Yes, that's the biggest issue.

Darwin platform binary dependencies in artifact bundles (personally, I think that's a non-goal since we already have XCFrameworks)

Agree, that's just fine I think - one can have two conditionalized dependencies (thanks to SE-0273) in that case - not perhaps as nice as a single dependency (as we push the work on our customers instead of hiding it), but definitely liveable and not a showstopper in any way.

Library evolution for non-Darwin platforms (this isn't even really a SwiftPM topic)

Well, in Xcode there's BUILD_LIBRARY_FOR_DISTRIBUTION - as far as I've been able to gather there's no similar setting using SwiftPM - that is why I brought it up - we'd like to build our packages with SwiftPM to generate the libraries using library evolution mode. Currently there's no good way to do that AFAICT.

Building a binary dependency from a package (I think it might also be a non-goal to do this in SwiftPM for Darwin platforms, because we don't really support building for anything but macOS and even there support is limited, e.g. in terms of resource types)

Well, after googling a bit it seems one could use e.g. swift-create-xcframework, but it would be desirable that the same SwiftPM package could be used to generate a dynamic library that is able to be packaged for multiple platforms (even if that packaging might differ) - we don't have any Xcode projects for any of our code, we just only use SwiftPM (as we want portability).

Only the first one is really needed for the main topic of this particular issue, right?

I think the other two would be needed as well to be able to build versioned resilient libraries?

[neonichu]

Right, there is no equivalent to BUILD_LIBRARY_FOR_DISTRIBUTION in SwiftPM and eventually there should be. But for the time being, I would recommend building with xcodebuild instead and passing that setting as an override (note that you can use xcodebuild for standalone packages, there is no requirement for having an Xcode project).

Non-Darwin platforms do not currently offer ABI stability for Swift, so you can just use a regular release build for those.

[hassila]

Right, there is no equivalent to BUILD_LIBRARY_FOR_DISTRIBUTION in SwiftPM and eventually there should be. But for the time being, I would recommend building with xcodebuild instead and passing that setting as an override (note that you can use xcodebuild for standalone packages, there is no requirement for having an Xcode project).

Non-Darwin platforms do not currently offer ABI stability for Swift, so you can just use a regular release build for those.

We’d like to use that on Linux too - according to the blog post linked above it should be possible to use library evolution mode on Linux too if matching tool chains :

Platform support
The Swift compiler currently only guarantees binary compatibility among different compiler versions on Apple platforms. This means that on Linux and other platforms, an application and a library built with different versions of the Swift compiler will not necessarily link or behave correctly at runtime.

However, stable module interfaces and library evolution can be used on all platforms supported by Swift. So on non-Apple platforms, you can still use multiple versions of the same library without recompiling a client application, as long as all binaries were built with the same version of the Swift compiler.

As mentioned in ABI stability and more, as development of Swift on Linux, Windows, and other platforms matures, the Swift Core Team will evaluate stabilizing the ABI on those platforms as well. This will lift the restriction on mixing and matching artifacts built with different compiler versions.

We are fine enforcing identical compiler versions on Linux, yet we’d like to use stable module interfaces and evolution to allow for selectively upgrading shared libraries. We’ll always ensure the same tool chain versions are used by our customers.

[hassila]

(So the need to pass that on Linux remains even if it’s useful to know about the Xcodebuild workaround on macOS, thanks)

[neonichu]

Ah interesting, I wasn't aware of that. Yes, I guess that means we'll want to support it.

You can try directly passing the compiler flags via -Xswiftc as a workaround, but I believe there was an issue with the generation .swiftinterface files in that case.

[hassila]

Hmmm.

I'm starting playing with it to see what can be done (on macOS to start) and adding a couple of unsafe flags
to the package/library:

import PackageDescription

let package = Package(
    name: "prototype-library-evolution",
    products: [
        .library(
            name: "PrototypeLibraryEvolution",
            type: .dynamic,
            targets: ["PrototypeLibraryEvolution"]),
    ],
    dependencies: [
    ],
    targets: [
        .target(
            name: "PrototypeLibraryEvolution",
            dependencies: [],
            swiftSettings: [.unsafeFlags(["-enable-library-evolution",
                                         "-emit-module-interface"])])
    ]
)

actually gave me a .swiftinterface file as well as the .dylib when building the library:

hassila@max ~/G/prototype-library-evolution (main)> ls .build/arm64-apple-macosx/debug/
ModuleCache/                                      PrototypeLibraryEvolution.private.swiftinterface  PrototypeLibraryEvolution.swiftinterface          description.json                                  prototype-library-evolutionPackageTests.product/
PrototypeLibraryEvolution.abi.json                PrototypeLibraryEvolution.product/                PrototypeLibraryEvolution.swiftmodule             index/
PrototypeLibraryEvolution.build/                  PrototypeLibraryEvolution.swiftdoc                PrototypeLibraryEvolution.swiftsourceinfo         libPrototypeLibraryEvolution.dylib*
hassila@max ~/G/prototype-library-evolution (main)> 

Then trying to build a client of this library failed:
I tried the simplest thing I could think of and declared an enum to be able to test non-frozen structs (SE-0192) with
@unknown default:, but a trivial test client app using the library does not seem to recognise it is
built/should use evolution mode so I get a warning:

/Users/hassila/GitHub/prototype-library-evolution-client/Sources/prototype-library-evolution-client/prototype_library_evolution_client.swift:21:9: warning: default will never be executed
        @unknown default:
        ^

It seems SwiftPM is too smart and will statically link when there's a local dependency even when the product
is defined to have the type .dynamic.

hassila@max ~/G/prototype-library-evolution-client (main) [1]> ls .build/arm64-apple-macosx/debug
ModuleCache/                                            PrototypeLibraryEvolution.swiftmodule                   prototype-library-evolution-client*                     prototype_library_evolution_client.build/
PrototypeLibraryEvolution.abi.json                      PrototypeLibraryEvolution.swiftsourceinfo               prototype-library-evolution-client.product/             prototype_library_evolution_client.swiftdoc
PrototypeLibraryEvolution.build/                        description.json                                        prototype-library-evolution-clientPackageTests.product/ prototype_library_evolution_client.swiftmodule
PrototypeLibraryEvolution.swiftdoc                      index/                                                  prototype_library_evolution_client.abi.json             prototype_library_evolution_client.swiftsourceinfo
hassila@max ~/G/prototype-library-evolution-client (main)> ls .build/arm64-apple-macosx/debug/PrototypeLibraryEvolution.build/
PrototypeLibraryEvolution-Swift.h        PrototypeLibraryEvolution.swift.o        master.priors                            module.modulemap
PrototypeLibraryEvolution.d              PrototypeLibraryEvolution.swiftdeps      master.swiftdeps                         output-file-map.json
PrototypeLibraryEvolution.emit-module.d  PrototypeLibraryEvolution.swiftdeps~     master.swiftdeps~
hassila@max ~/G/prototype-library-evolution-client (main)> 

I'll see if I can wrap it as a binary dependency (XCFramework) instead and if that makes a difference.

[hassila]

I wrapped it as an xcframework and that works - but only in Xcode - not from the command line - details here for anyone interested.

[hassila]

Another question came up now when I played with this a bit more when validating your fix for the XCFramework search paths.

It seems SwiftPM copies the binary target dependencies (shared library) to the build directory and use it from there -
that is a bit undesirable if enabling library evolution mode and wanting to truly share the shared library across multiple consumers of the framework - I'd expect SwiftPM to link vs. the XCFramework in the location where it is located rather than copying it over to the build for the project I'm doing - as least as an option.

I tested it on Linux (did a simple POC by enabling .xcframework in my local toolchain for linux and handcrafted a Linux .xcframework just for validation) and could see this when checking what was actually dynamically loaded:

ubuntu@swift ~/p/PrototypeLibraryEvolution.xcframework (main) [1]> sudo pldd 61802
61802:	/home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient
linux-vdso.so.1
/usr/lib/swift/linux/libswiftGlibc.so
/lib/aarch64-linux-gnu/libm.so.6
/lib/aarch64-linux-gnu/libpthread.so.0
/lib/aarch64-linux-gnu/libutil.so.1
/lib/aarch64-linux-gnu/libdl.so.2
/usr/lib/swift/linux/libswift_Concurrency.so
/usr/lib/swift/linux/libswiftCore.so
/usr/lib/swift/linux/libswiftSwiftOnoneSupport.so
***** /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/libPrototypeLibraryEvolution.so *****
/lib/aarch64-linux-gnu/libc.so.6
/lib/aarch64-linux-gnu/libstdc++.so.6
/lib/aarch64-linux-gnu/libgcc_s.so.1
/lib/ld-linux-aarch64.so.1
/usr/lib/swift/linux/libdispatch.so
/lib/aarch64-linux-gnu/librt.so.1
/usr/lib/swift/linux/libBlocksRuntime.so

I could see in the build log that the first thing done was copying the .so

Building for debugging...
***** Copying /home/ubuntu/prototype-library-evolution/PrototypeLibraryEvolution.xcframework/linux-aarch64/libPrototypeLibraryEvolution.so *****
/usr/bin/swiftc -module-name PrototypeLibraryEvolutionClient -incremental -emit-dependencies -emit-module -emit-module-path /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.swiftmodule -output-file-map /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/output-file-map.json -c /home/ubuntu/prototype-library-evolution-client/Sources/PrototypeLibraryEvolutionClient/PrototypeLibraryEvolutionClient.swift -I /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug -target aarch64-unknown-linux-gnu -swift-version 5 -enable-batch-mode -index-store-path /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/index/store -Onone -enable-testing -g -j8 -DSWIFT_PACKAGE -DDEBUG -I /home/ubuntu/prototype-library-evolution/PrototypeLibraryEvolution.xcframework/linux-aarch64 -Xcc -I -Xcc /home/ubuntu/prototype-library-evolution/PrototypeLibraryEvolution.xcframework/linux-aarch64 -module-cache-path /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/ModuleCache -parseable-output -Xfrontend -entry-point-function-name -Xfrontend PrototypeLibraryEvolutionClient_main -parse-as-library -F /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug -color-diagnostics -v
Swift version 5.6.2 (swift-5.6.2-RELEASE)Target: aarch64-unknown-linux-gnu/usr/bin/swift-frontend -frontend -c -primary-file /home/ubuntu/prototype-library-evolution-client/Sources/PrototypeLibraryEvolutionClient/PrototypeLibraryEvolutionClient.swift -emit-dependencies-path /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.d -emit-reference-dependencies-path /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.swiftdeps -target aarch64-unknown-linux-gnu -Xllvm -aarch64-use-tbi -disable-objc-interop -I /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug -I /home/ubuntu/prototype-library-evolution/PrototypeLibraryEvolution.xcframework/linux-aarch64 -F /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug -color-diagnostics -enable-testing -g -module-cache-path /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/ModuleCache -swift-version 5 -Onone -D SWIFT_PACKAGE -D DEBUG -new-driver-path /usr/bin/swift-driver -entry-point-function-name PrototypeLibraryEvolutionClient_main -resource-dir /usr/lib/swift -enable-anonymous-context-mangled-names -Xcc -I -Xcc /home/ubuntu/prototype-library-evolution/PrototypeLibraryEvolution.xcframework/linux-aarch64 -module-name PrototypeLibraryEvolutionClient -parse-as-library -o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.swift.o -index-store-path /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/index/store -index-system-modules
/usr/bin/swift-frontend -frontend -emit-module -experimental-skip-non-inlinable-function-bodies-without-types /home/ubuntu/prototype-library-evolution-client/Sources/PrototypeLibraryEvolutionClient/PrototypeLibraryEvolutionClient.swift -target aarch64-unknown-linux-gnu -Xllvm -aarch64-use-tbi -disable-objc-interop -I /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug -I /home/ubuntu/prototype-library-evolution/PrototypeLibraryEvolution.xcframework/linux-aarch64 -F /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug -color-diagnostics -enable-testing -g -module-cache-path /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/ModuleCache -swift-version 5 -Onone -D SWIFT_PACKAGE -D DEBUG -new-driver-path /usr/bin/swift-driver -entry-point-function-name PrototypeLibraryEvolutionClient_main -resource-dir /usr/lib/swift -enable-anonymous-context-mangled-names -Xcc -I -Xcc /home/ubuntu/prototype-library-evolution/PrototypeLibraryEvolution.xcframework/linux-aarch64 -module-name PrototypeLibraryEvolutionClient -emit-module-doc-path /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.swiftdoc -emit-module-source-info-path /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.swiftsourceinfo -parse-as-library -o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.swiftmodule -emit-abi-descriptor-path /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.abi.json
/usr/bin/swift-frontend -modulewrap /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.swiftmodule -target aarch64-unknown-linux-gnu -o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.o
/usr/bin/swift-autolink-extract /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.swift.o -o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.autolink
/usr/bin/swiftc -modulewrap /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.swiftmodule -o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.swiftmodule.o -target aarch64-unknown-linux-gnu
/usr/bin/swiftc -lPrototypeLibraryEvolution -F /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug -L /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug -o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient -module-name PrototypeLibraryEvolutionClient -emit-executable -Xlinker --defsym -Xlinker main=PrototypeLibraryEvolutionClient_main -Xlinker '-rpath=$ORIGIN' @/home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.product/Objects.LinkFileList -target aarch64-unknown-linux-gnu -v -L /usr/lib
Swift version 5.6.2 (swift-5.6.2-RELEASE)
Target: aarch64-unknown-linux-gnu
/usr/bin/swift-autolink-extract /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.swift.o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.swiftmodule.o -o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.autolink
/usr/bin/clang -fuse-ld=gold -pie -Xlinker -rpath -Xlinker /usr/lib/swift/linux /usr/lib/swift/linux/aarch64/swiftrt.o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.swift.o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.swiftmodule.o @/home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.autolink -F /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug -L /usr/lib/swift/linux -lswiftCore --target=aarch64-unknown-linux-gnu -v -L /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug -L /usr/lib -lPrototypeLibraryEvolution -Xlinker --defsym -Xlinker main=PrototypeLibraryEvolutionClient_main -Xlinker '-rpath=$ORIGIN' -o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient
clang version 13.0.0 (https://github.com/apple/llvm-project.git f765bf5b71fd3637a6f6d1d3e6ab95ca91892a0c)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/9
Selected GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/9
Candidate multilib: .;@m64
Selected multilib: .;@m64
clang-13: warning: argument unused during compilation: '-F/home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug' [-Wunused-command-line-argument]
 "/usr/bin/ld.gold" -pie -EL -z relro --hash-style=gnu --eh-frame-hdr -m aarch64linux -dynamic-linker /lib/ld-linux-aarch64.so.1 -o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient /lib/aarch64-linux-gnu/Scrt1.o /lib/aarch64-linux-gnu/crti.o /usr/bin/../lib/gcc/aarch64-linux-gnu/9/crtbeginS.o -L/usr/lib/swift/linux -L/home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug -L/usr/lib -L/usr/bin/../lib/gcc/aarch64-linux-gnu/9 -L/lib/aarch64-linux-gnu -L/usr/lib/aarch64-linux-gnu -L/usr/bin/../lib -L/lib -L/usr/lib -rpath /usr/lib/swift/linux /usr/lib/swift/linux/aarch64/swiftrt.o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.swift.o /home/ubuntu/prototype-library-evolution-client/.build/aarch64-unknown-linux-gnu/debug/PrototypeLibraryEvolutionClient.build/PrototypeLibraryEvolutionClient.swiftmodule.o -lswiftGlibc -lm -lpthread -lutil -ldl -lswift_Concurrency -lswiftCore -lswiftSwiftOnoneSupport -lswiftCore -lPrototypeLibraryEvolution --defsym main=PrototypeLibraryEvolutionClient_main "-rpath=\$ORIGIN" -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib/gcc/aarch64-linux-gnu/9/crtendS.o /lib/aarch64-linux-gnu/crtn.o
Build complete! (0.73s)

To me this is related to have the full support for library evolution using shared libraries, but maybe that should be broken out as a separate case from supporting the binaryTarget (both are needed to reach the end goal though, to be able to build shared libraries that use library evolution support and that can be shared across multiple consumer of the library - just as for system framework from Apple)