Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPM problems with loading duplicate libs when using modules / frameworks #265

Open
npvisual opened this issue Aug 18, 2020 · 3 comments
Open

Comments

@npvisual
Copy link
Contributor

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
Copy link
Contributor Author

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

@npvisual
Copy link
Contributor Author

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants