Error: Could not find or use auto-linked library ‘swiftCompatibility*’: library ‘swiftCompatibility*’ not found

Same issue. I found possible solution here: https://github.com/zalando/SwiftMonkey/issues/80#issuecomment-604994492

Create an Empty Swift file using Xcode, such as named Void.swift, and every issue will be solved by Xcode automatically. If you want to know what Xcode has done, submit the code before creating the file, and check the changes after creating the file.

But this solution requires you to fork problem package (in this case Amplitude)

This is still an issue with Tuist 4.9

Hey 👋

I can take a look but I can’t reproduce the issue when I add this library to our spm fixture. Would someone be able to attach a zip with the full reproducible project? That would be greatly appreciated 🙌

I was able to fix the error by defining the framework as dynamic framework in the Package.swift.

#if TUIST
import ProjectDescription
import ProjectDescriptionHelpers

let packageSettings = PackageSettings(
	productTypes: [
		"LibWhichCausesTheError": .framework,
	]
)
#endif

My two cents are that is that is related to the issue mentioned here. A framework is linking static binaries whose symbols end up in the public module of the framework. @MartinStrambach could you try setting the build setting GENERATE_MASTER_OBJECT_FILE=YES in the dynamic target that’s closest to LibWhichCausesTheError when navigating the graph upstream?

Tried it, but it doesn’t help. In my case, it happens due to Nimble dependency in tests. ld: warning: Could not find or use auto-linked library 'swiftCompatibility56': library 'swiftCompatibility56' not found ld: warning: Could not find or use auto-linked library 'swiftCompatibilityConcurrency': library 'swiftCompatibilityConcurrency' not found ld: warning: Could not find or use auto-linked library 'swiftCompatibilityPacks': library 'swiftCompatibilityPacks' not found Undefined symbols for architecture arm64: "__swift_FORCE_LOAD_$_swiftCompatibility56", referenced from: __swift_FORCE_LOAD_$_swiftCompatibility56_$_CwlCatchException in CwlCatchException[3](CwlCatchException.o) __swift_FORCE_LOAD_$_swiftCompatibility56_$_CwlPreconditionTesting in CwlPreconditionTesting[3](CwlBadInstructionException.o) __swift_FORCE_LOAD_$_swiftCompatibility56_$_Nimble in Nimble[3](AdapterProtocols.o) "__swift_FORCE_LOAD_$_swiftCompatibilityConcurrency", referenced from: __swift_FORCE_LOAD_$_swiftCompatibilityConcurrency_$_CwlCatchException in CwlCatchException[3](CwlCatchException.o) __swift_FORCE_LOAD_$_swiftCompatibilityConcurrency_$_CwlPreconditionTesting in CwlPreconditionTesting[3](CwlBadInstructionException.o) __swift_FORCE_LOAD_$_swiftCompatibilityConcurrency_$_Nimble in Nimble[3](AdapterProtocols.o) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

You also said in the dynamic target that's closest to LibWhichCausesTheError when navigating the graph upstream. I don’t think there’s any dynamic target when navigating the graph upstream because my target which links Nimble is just the test target.

You also said in the dynamic target that’s closest to LibWhichCausesTheError when navigating the graph upstream. I don’t think there’s any dynamic target when navigating the graph upstream because my target which links Nimble is just the test target.

In that case a target that can link static binaries, the test target in this case. I assume if you setGENERATE_MASTER_OBJECT_FILE=YES, you get the above issue right? Do you know where the symbols swiftCompatibility56… are coming from?

I am currently facing the same problem, in my case FirebaseCore fails to compile when i put "FirebaseCore": .framework, in package settings. Putting in all the dependencies of FirebaseCore doesn’t seem to make a difference. Did anyone find a workaround?

I am currently facing the same problem, in my case FirebaseCore fails to compile when i put "FirebaseCore": .framework, in package settings. Putting in all the dependencies of FirebaseCore doesn’t seem to make a difference. Did anyone find a workaround?

For a framework that uses Firebase Auth and GoogleSignIn, keeping FirebaseCore, GoogleSignIn, GTMAppAuth and GTMSessionFetcherCore as .staticFramework in PackageSettings solves the linking problem.

But then I get this type of warnings:

Target 'FirebaseCore' has been linked from target 'A' and target 'FirebaseAuth', it is a static product so may introduce unwanted side effects.

where A is another (internal) framework that uses Firebase thus indirectly FirebaseCore.

As per our discussion in Slack, here is the link to sample project with this issue: https://github.com/hf-anton-kolchunov/tuist-sample-project

I have similar issue. I have tried a few workarounds mentioned here but none of them works