I updated one of my core frameworks to use Swift as an experiment. It builds fine, the compatibility header has the Swift classes available to the Objective-C classes that depend on them, and everything compiles fine.
However, when launching the application (base SDK and deployment target OS X 10.10) it crashes immediately with:
dyld: Library not loaded: #rpath/libswift_stdlib_core.dylib
Referenced from: /Users/Craig/Library/Developer/Xcode/DerivedData/MacApp-dxcgahgplwpbjedqnembegifbowj/Build/Products/Debug/Fluffy.framework/Versions/A/Fluffy
Reason: image not found
Note that MacApp is the application I'm launching, and it uses the Fluffy framework containing Swift code.
The Fluffy project has its Runpath Search Paths set to:
#executable_path/Frameworks
But I have also tried it blank. I have tried restarting Xcode, to no avail. Using Yosemite 14A298i and Xcode beta 4.
The Runpath Search Paths for my framework (Fluffy) containing the Swift code needed to be updated. It originally contained:
$(inherited)
#executable_path/../Frameworks
But after creating a sample Swift project and comparing the build settings, Xcode was adding:
#loader_path/Frameworks
To the newly-created project. This was missing from my existing framework project. Adding it so the Runpath Search Paths contained these values solved the problem:
$(inherited)
#executable_path/../Frameworks
#loader_path/Frameworks
If you faced Library not loaded error in run time you should add those libraries in Embedded Binary.
Step 01 :-
Make sure that library is in the current project Navigation. If not Drag and drop library in to your project navigation.
Step 02 :-
Click on project > General > Embedded Binary > Add library which showed in your error. In this case you should add libswift_stdlib_core.
Related
I have an iOS project in XCode 11.2 that requires a mix of Frameworks, some of which are available on Cocoapods and some are not. For the non-Cocoapod frameworks, I have the frameworks copied to the root of my project folder.
The trouble comes with getting XCode to be able to find both using the Framework Search Paths setting as shown here:
All of the entries following $(inherited) are actually the ones inherited from Cocoapods (these are not explicitly specified).
If I don't add the $(PROJECT_DIR) at the end then Cococapod frameworks are found fine, but my embedded non-Cocoapod frameworks get compiler errors that their header files are not found.
If I do add the $(PROJECT_DIR) at the end, then the Cocoapod frameworks are not found and I get a build error like:
ld: warning: directory not found for option '-F/Users/dyoung/Library/Developer/Xcode/DerivedData/MyApp-acdmyjbbrpbhlkfiyypetovwacrz/Build/Products/Debug-iphoneos/AWSAuthCore'
...
ld: framework not found AWSAuthCore
Why? How do I get XCode to find frameworks in both places?
Here's one way:
pod deintegrate
Open the .xcodeproj
Add the non-CocoaPods frameworks.
pod install
Open the .xcworkspace
The problem was that the CocoaPods Frameworks that I was trying to add were built only for iOS 11+, but my very old project had a deployment target of iOS 8.4.
Looking at error details in the Report Navigator as #paul-beusterien suggested was critical. I found this:
Ld /Users/dyoung/Library/Developer/Xcode/DerivedData/MyApp-acdmyjbbrpbhlkfiyypetovwacrz/Build/Intermediates.noindex/MyApp.build/Debug-iphoneos/MyApp.build/Objects-normal/armv7/Binary/MyApp normal armv7 (in target 'MyApp' from project 'MyApp')
The key thing there is the armv7 architecture. This architecture is only part of the build process if you have a deployment target of 10.x or earlier but not if you have 11.x or later. And if the frameworks you are including don't have armv7 architecture (e.g. if they are built for 11.0+), XCode gives very misleading error messages about the frameworks not being found. What really isn't found is that specific architecture inside the framework.
Bottom line: My problem had nothing to do with framework search paths. Removing $(PROJECT_DIR) from the framework search path only appeared to solve the problem by triggering a different compile-time problem to happen before it got to the linker problem.
The solution in this case is that I must change my deployment target to 11.0, then everything builds properly.
We have a working Mac OS X screensaver as a standalone Xcode project, but we needed to have it as a target in another Xcode project that also contains a related app.
I added a target for a screensaver, copied the code, added to that target, etc, etc. The code is the same one that works in the other screensaver, but on this one, it generates the following error:
2015-03-10 09:43:24.766 System Preferences[32495]: Error loading /Users/pupeno/Library/Screen Savers/Ninja.saver/Contents/MacOS/Ninja: dlopen(/Users/pupeno/Library/Screen Savers/Ninja.saver/Contents/MacOS/Ninja, 265): Library not loaded: #rpath/libswiftAppKit.dylib
Referenced from: /Users/pupeno/Library/Screen Savers/Ninja.saver/Contents/MacOS/Ninja
Reason: image not found
2015-03-10 09:43:24.766 System Preferences[32495]: ScreenSaverModules: can't get principalClass for /Users/pupeno/Library/Screen Savers/Ninja.saver
The library in question is definitely there:
$ ls -w1 Library/Screen\ Savers/Ninja.saver/Contents/Frameworks/
libswiftAppKit.dylib
libswiftCore.dylib
libswiftCoreGraphics.dylib
libswiftDarwin.dylib
libswiftDispatch.dylib
libswiftFoundation.dylib
libswiftObjectiveC.dylib
libswiftQuartzCore.dylib
libswiftSecurity.dylib
Any ideas what might be causing this?
The problem was that the Runpath Search Path, for some reason, in this new target, was blank. I fixed this problem by adding this:
#executable_path/../Frameworks #loader_path/../Frameworks
to it (which I took from the working screensaver configuration). This is how it looks like:
Like Pablo said, you need the following as your Runtime Search Path:
#executable_path/../Frameworks #loader_path/../Frameworks
This should be the default. Make sure it's there though. You also need to set Embedded Content Contains Swift Code to YES if you're using Swift. That took me awhile to figure out.
(Xcode should totally infer this. Oh well. I filed a radar for this awhile.)
I'm stuck with including a 3rd party framework (written in Objective-C) into my Swift application. I did the following (which should be sufficient):
Include the framework into the project
Add the framework to the "Link Binary with Libraries" build phase
Add the framework to the "Copy Files" build phase (destination: "Frameworks")
Import the main header of the framework into the bridging header
Compiling the project succeeds. But as soon as I try to run it I receive the following error:
dyld: Library not loaded: /Library/Frameworks/ZipKit.framework/Versions/A/ZipKit
Additionally I set the following settings:
Runpath Search Paths: #executable_path/../Frameworks
Framework Search Paths: #executable_path/../Frameworks (in addition to the source location of the framework)
Library Search Paths: #executable_path/../Frameworks
Nothing seems to work and I don't have any clue why the runtime keeps looking in the /Library folder.
I'm currently using Xcode 6 Beta 6 (as the GM does not support Swift on OS X).
Edit
Just to clarify: The app bundle contains the linked framework after compilation (I've checked that).
Found it.
Fortunately I have the source code of the framework I want to include.
I stumbled upon the install path setting of the framework project which was set to /Library/Frameworks.
I changed this to #executable_path/../Frameworks re-compiled it, re-compiled my project and now it works.
I'm trying to install a testing library for a project on top of SenTestingKit.
Prior to installing, the project builds fine and runs the test suite using SenTestingKit.
However, after using cocoapods to install another testing framework like Specta or Kiwi (which apparently depend on SenTestingKit), the project builds, but then immediately throws this error:
dyld: Library not loaded: #rpath/SenTestingKit.framework/Versions/A/SenTestingKit
Referenced from: [...]
Reason: image not found
I've tried about a dozen different suggestions from people with similar problems (changing the target build settings test host, changing the target framework search paths, etc, making sure pods are configured for the test target, etc.), all to no avail. Any suggestions?
Try with the following steps to link the static library to our project (which inturn uses a framework or static library):
Include the static library in the main projects "link binary with library".
Provided the header path at HEADER_SEARCH_PATH as well as LIBRARY_SEARCH_PATH (Inside Build Settings of app's target).
Most important:
In the target's build phases - > Link binaries with libraries set the relevant framework (SenTestKit.framework in our case) to "Optional" instead of "Required".
Hope this will fix your issue
Finally tracked down the answer.
Following the steps laid out in the answer here fixed the issue:
How to set dyld_library_path in Xcode
We have multiple development machines, some running Xcode 3.2.5 and others running Xcode 4.2. We have a static library that is referenced by our project. It contains Objective C categories, so we need to use the -force_load flag with the path to the library.
The problem that we are having is that on Xcode 4.2, the library is linked from a different location than the path that we specified in -force_load. This causes duplicate symbol errors since it's trying to link two copies of the same library.
The path Xcode 4.2 links from is:
/Users/USERNAME/Library/Developer/Xcode/DerivedData/PROJECTNAME-ehxeazvigqrpvogkxlkcmdzpisdw/Build/Products/CONFIGURATION-PLATFORM/
whereas the location that Xcode 3.2.5 links from is:
PROJECT_ROOT_OF_STATIC_LIBRARY/build/CONFIGURATION-PLATFORM/
Is there a way to get Xcode 4.2 to use the same locations as Xcode 3.2.5 when linking static libraries so that we can use the force_load linker option? If not, can anyone suggest an alternative solution to get Xcode 3.2.5 and 4.2 to play nicely together?
It sounds to me like you are doing things the hard way.
I've never used -force_load to load static libraries. With the libraries I use, they are all stored as frameworks in a directory on my system which is separate from the project. I then use the XCode standard add frameworks dialogs to bring them into the project and "-ObjC -all_load" to ensure they work and categories are active.
I've successfully move a few projects from XCode 3 to 4 and not had the problem you are mentioning. I suspect that if you can stop using -force_load your problems will go away.