SPM problems with loading duplicate libs when using modules / frameworks

[npvisual]

Description

Version info : Xcode 12.0 Build version 12A8179i

When using SPM to load RK in Xcode 12 Beta 4, for a project with multiple modules that leverage RK, I run into the following issue :

Swift package product 'ReactiveKit' is linked as a static library by 'Services' and 'API'. This will result in duplication of library code.

If I somehow manage to circumvent that message by linking "binaries with library" and only embedding the frameworks at the product level, the application will compile, but will result in crashes at runtime with warning messages when the application starts similar to :

Class _TtC11ReactiveKit15BlockDisposable is implemented in both moduleA and moduleB

Solution

I unfortunately haven't found many resources on this particular issue with SPM. However this git repo seems to highlight the same issue and mentions the following :

IMHO it's an Xcode issue. Because in SPM documentation, it's mentioned that if you don't want to force either .dynamic or .static you can let blank and it will be automatically manager by the SPM consumer (a.k.a Xcode in our case). Xcode should be smart enough to detect that a SPM library is used twice or more and apply the .dynamic itself or something.

So I gave it a shot, forked RK and forced it be loaded dynamically by using .dynamic in Package.swift. And it worked great. No more compilation issues and no runtime crash.

[npvisual]

Note : the same issue is seen with Bond. Same fix is suggested.

[npvisual]

Another approach would be to declare different libraries, each with the library type defined as illustrated in the SPM Package Description API documentation :

...
let package = Package(
    name: "Paper",
    products: [
        .executable(name: "tool", targets: ["tool"]),
        .library(name: "Paper", targets: ["Paper"]),
        .library(name: "PaperStatic", type: .static, targets: ["Paper"]),
        .library(name: "PaperDynamic", type: .dynamic, targets: ["Paper"]),
    ],
    dependencies: [
...

until Xcode is able to figure things out by itself (maybe there's a flag for that ™️?). This however might not be desirable...

[srdanrasic]

Thanks for working on this @npvisual. I think we should go with the additional product approach. It's more flexible option.

Hopefully in future one will be able to specify that at the point of use.