I've built an SDK as an XCFramework, which shares dependencies with the app that uses it. When I build, I'm getting:
...SDK.swiftmodule/arm64-apple-ios.swiftinterface:20:8: Cannot load underlying module for...
This occurs in the Compile Swift Sources action and the break is in the import MySharedDepedency statement in the swiftinterface file
As stated, the SDK in the project as an xcframework bundle. MySharedDependency is fulfilled with cocoapods. use_modular_headers is set in the Podfile, it's modulemap is included in the linker flags (by cocoapods).
Its DOES work if I use the use_frameworks! flag in the Podfile but only with dynamic linkage and for internal politics reasons, I need this to work with static linkage. If I add the :linkage => :static argument, I get the same error as with no use_frameworks! call
I've tried changing the order of the linked frameworks in Build Phases (so that the pods are linked before the SDK framework). I've tried adding recursive header/framework/module search paths everywhere I can find a MyDependency.modulemap...
Yes, I've cleaned caches, deintegrated, clean installed, erased deriveddata, restarted xcode, my machine, ...
Argh! Thanks for any help...
I had the same exactly the same scenario and the same problem
I solved using #_implementationOnly in every file from my xcframework's code like:
#_implementationOnly import Alamofire
After that just rebuild your XCFramework, clean and build your app's project.
It works like a charm without use_frameworks!
I have my custom framework, let's call it TestFramework, and project, in which I want to include that framework, lets call it TestProject.
TestFramework use libraries, such as Alamofire, which I added to TestFramework using Carthage. When I added TestFramework to TestProject, the project wouldn't compile until I added Alamofire (and the other libraries that exist in TestFramework) using Cocoapods to TestProject. This worked until I updated Xcode to version 10. Now, when I try to access libraries methods in TestFramework, I get this:
No error description provided, and I am using latest version of Alamofire.
I am using GVRSDK library pod in my custom framework but if i add this some other project target its not getting import. I am using module map because the library was not getting import in custom framewotk
error: using bridging header with framework target is unsupported.
Compilation Error due to adding private header in umbrella header Include of non modular header inside framework module .
Next i added Module Map File it got imported in Framework swift file. If i
import it in some other swift target it throwing error module not found.
You should speciafied in your Podfile for which target you wanna install your pods
target 'FrameworkName' do
use_frameworks!
pod 'GVRSDK'
end
After that you can add the framework to your app from Build Phases -> Embed Frameworks
I'm trying to add a static framework (Moya) to my private Cocoapod project through Carthage.
My goal is to include Moya as a static framework in my private Cocoapod (SwiftModel) and use Moya as well in my main project (as SwiftModel has a dependency to it).
I've added Moya to my framework by doing the following steps:
link framework in podspec file
s.vendored_frameworks = 'SwiftModel/Carthage/Build/iOS/Moya.framework'
add Moya to private framework (Link Binary With Libraries)
So inside my Pods project it looks like this:
Trying to add the path to "Framework Header Search Path" did not made any changes. I've tried to add it in the main project and in pods project.
When just building the private pod everything works fine and Moya is recognized. However if I want to build the main project (that includes my private pod) I'm always getting this error:
framework not found Moya for architecture arm64
As your error states that
framework not found Moya for architecture arm64
It means that Moya is not available for arm64 architecture, but your main project has following architectures;- arm64, armv7, armv7s. Remove the arm64 from your main project's valid architecture.
Also try to add -Objc in other link flags.
Try adding libz to the link library section of you project
iOS Support matrix:-
I have a framework written in obj-c and swift.
Now i try to run a related unit test target, but I get this error:
2014-07-10 07:45:54.064 xctest[4908:303] The test bundle at /Users/steve/Temporary/Build/Products/Debug/SOGraphDB-Mac Tests.xctest could not be loaded because an unanticipated error occurred: Error Domain=NSCocoaErrorDomain Code=3587 "The bundle “SOGraphDB-Mac Tests” couldn’t be loaded because it is damaged or missing necessary resources." (dlopen_preflight(/Users/steve/Temporary/Build/Products/Debug/SOGraphDB-Mac Tests.xctest/Contents/MacOS/SOGraphDB-Mac Tests): Library not loaded: #rpath/libswiftAppKit.dylib
Referenced from: /Users/steve/Temporary/Build/Products/Debug/SOGraphDB.framework/Versions/A/SOGraphDB
Reason: image not found) UserInfo=0x10011c640 {NSLocalizedFailureReason=The bundle is damaged or missing necessary resources., NSLocalizedRecoverySuggestion=Try reinstalling the bundle., NSFilePath=/Users/steve/Temporary/Build/Products/Debug/SOGraphDB-Mac Tests.xctest/Contents/MacOS/SOGraphDB-Mac Tests, NSDebugDescription=dlopen_preflight(/Users/steve/Temporary/Build/Products/Debug/SOGraphDB-Mac Tests.xctest/Contents/MacOS/SOGraphDB-Mac Tests): Library not loaded: #rpath/libswiftAppKit.dylib
Referenced from: /Users/steve/Temporary/Build/Products/Debug/SOGraphDB.framework/Versions/A/SOGraphDB
Reason: image not found, NSBundlePath=/Users/steve/Temporary/Build/Products/Debug/SOGraphDB-Mac Tests.xctest, NSLocalizedDescription=The bundle “SOGraphDB-Mac Tests” couldn’t be loaded because it is damaged or missing necessary resources.}
Any idea what the root cause can be?
The error seems realated to "Library not loaded: #rpath/libswiftAppKit.dylib"
Both (framework and test bundle) compile without any error or warning (in Beta2)
I had a similar problem, though mine was an iOS test target, linking to a Swift framework, that failed to run on Xcode 6 GM. The test target had run successfully on an early beta of Xcode 6, but the final version reported the runtime error: Library not loaded: #rpath/libswiftCore.dylib
I noticed that a newer project did not have the failure, so I compared the build settings and test code. I was able to resolve the problem with three steps:
The test target needs the "Embedded Target Contains Swift Code" setting to be YES. This tells the linker to add the Swift runtime libraries to the executable.
The test target needs an explicit value for the "Runpath Search Paths" build setting. This tells the loader where to find the Swift runtime libaries. I copied the following setting from a fresh new test target:
LD_RUNPATH_SEARCH_PATHS = $(inherited) #executable_path/../Frameworks #loader_path/../Frameworks
The test cases need to explicitly import any modules that are used by the linked framework. In my project, the framework used UIKit but the test cases only used my framework. When I added an explicit import UIKit to the test cases, the link problem went away.
Since I keep running into this issue whenever I mess with build settings, here's the cleanest answer I can provide as of Xcode 8b5:
If unit tests don't run on iOS, make sure you have:
Runpath Search Paths: #loader_path/Frameworks
If unit tests don't run on macOS, make sure you have:
Runpath Search Paths: #loader_path/../Frameworks
This will show up as LD_RUNPATH_SEARCH_PATHS in your pbxproj file. You can also add $(inherited) to make sure project-wide paths are added as well, but those are probably empty.
Lastly, I didn't need the executable_path/... settings, doesn't make a difference for me whether they're there or not for unit tests.
I had the same problem.
Ended up copying libswiftAppKit.dylib out of the Xcode application directory (I am using beta 3), into a directory that I could reference (not part of an application bundle), then adding the library to the "Link binary with libraries" setting for the test bundle. My tests then started working.
FYI, the path for the dylib was at '/Applications/Xcode6-Beta3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/libswiftAppKit.dylib'
Probably not a good final solution, but it works for the interim.
My solution was to add a single file to my test target, AppKitTests.swift (or AppKitSpec.swift in my case), and all the file contains is:
// While I don't know why, The.framework is built linked to libswiftAppKit.
// Frameworks do not embed the Swift libraries themselves, it's up to the host
// app to include the necessary libraries. So here we are, including AppKit on
// behalf of The.framework so that the tests can run.
import AppKit
Oh, I also added AppKit to the test target's set of frameworks.
I had this occur to me in Beta 4 and it turned out that I had done it to myself without realizing it.
I had a Framework project called Fnord. My FnordTests target contained a couple of unit test classes that had import Fnord at the top of each file. For some reason Xcode was complaining about those imports and so I commented them out. This is when I started getting the same symptoms while trying to run my unit tests.
I noticed that the settings for my FnordTests target were such that the target would be linked with Fnord.framework, and I realized that it might not be able to do that with the aforementioned import Fnord statements diked-out.
So I put them back in, and everything went back to normal. Curiously, Xcode no longer showed those import statements as being problematic, but this is beta so I can forgive that.
I hope this helps someone.
I ran into the same issue, adding
import AppKit
in the Swift file fixed it