I've created an iOS framework project using the famous (and excellent) iOS Universal Framework Xcode template.
But now I've encountered an annoying problem that I can't seem to fix which is that I have an iOS application project that references the framework project and when I run that and have breakpoints set in the framework they don't get it. It seems GDB doesn't have the debug symbols for the framework.
I've made sure that debug symbols are not stripped from the framework and the type is set to "DWARF with dSYM file".
Anyone have any ideas what might be wrong and how to fix it?
My setup:
Xcode 4.2.1
iOS SDK 5.0
I ran into this issue while linking a dynamic framework to a test application in Xcode 7. I was able to avoid the error by ensuring the following in the build settings of my dynamic framework:
"Generate Debug Symbol" - 'Yes'
"Strip Debug Symbols During Copy" - 'No'
Several things comes to my mind regarding your problem. Give them a try and see which ones work for you:
Make sure to have the "Other Linker Flags" on the "Linking" section of the framework's "Build" Info.
Make sure that you have the framework's built in the correct configuration (ie, if you compiled the framework's in Release and are using it with your project set to Debug you might get issues)
Make sure you added the correct framework .a file to your project (actually two issues here: you can have added the Release version - so no debug symbols in there - AND you have to make sure that your projec is not pointing to some old build version)
Check that both the framework's and your project have the "Level of Debug Symbols" on the "Code Generation" section of the "Build" Info set to "All Symbols [full, -gstabs+ -fno-eliminate-unused-debug-symbols]"
If all alse fails try to empty the XCode caches and remove the framework reference from your project. Then clean and rebuild the framework (all configs: device-debug, device-release, simulator-debug, simulator-release, ...) and add it again to you project. Clean and rebuild your project and cross your fingers... :-)
I have also experienced this issue. One way that I have been able to work around this by merging both projects into a single workspace.
Instructions on how to do this can be found at http://developer.apple.com/library/ios/#recipes/xcode_help-structure_navigator/articles/adding_a_project_to_a_workspace.html.
NOTE: I have also experienced a bug adding projects to workspaces where there appears to be no files in the recently added project to the workspace. I have found this is easily remedied by restarting Xcode after all of the projects have been added to the workspace.
Related
I'm importing a newer version of a custom framework LCCommLibrary that creates the LCConnection class and I'm absolutely perplexed why this will build but not archive after trying multiple things.
Making sure the targets are added (4 apps, 1 Test)
Cleaning and Restarting the Project
This does builds and runs to my iOS devices, but none of the targets will Archive.
Archive usually uses the Release build configuration while building/running on the device uses the Debug build configuration, this is the hint that you have an issue there.
I would say in your case you can to go into the target's build settings, then look at Other Linker Flags, Runpath Search Paths and Library Search Paths, expand them to show the Debug and Release configurations and then ensure you have the same settings for both of them, you'll most probably find something missing in release in one of those.
Finally found the issue. The culprit was framework that was included was a debug version of the framework. This causes Archive Schemes to throw this error since the archive uses the Release as the default.
The resolution was to open the LCCommLibrary Project separately, change the Framework Target's Run Scheme to Release, Run and Build, Locate the target framework, import and embed that back into main project file, and archive as usual.
I have just recently upgraded to Xcode 7 and now I get this warning:
ld: warning: directory not found for option '-F/Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.0.sdk/Developer/Library/Frameworks'
I researched different forums and everybody with similar issue recommends to remove paths from build settings but I can't find any paths there resembling iPhone simulators....
I had the same issue, here are the steps that worked for me
open your project
got to TARGETS
select youAppNameTests
select Build Settings
Framework Search Paths
Delete every thing from Debug and Release fields
clean project
Hope it will work for you too
The problem has to do with the test target. Delete your test target. (Copy the code out to some other program if there is any.) Quit Xcode and clean out the Derived Data folder. Now open your project again, and the problem will be gone. If necessary, now make a new test target.
I have an XCode workspace created with XCode 6.0.1. It constains 2 (Swift) libraries and one iOS app (Swift) that depends on those 2 libraries. I had stable setup that allowed me to run the iOS app on both iPhone and simulators: The 2 library projects were added as Embedded Binaries (see picture) of the app.
Now, I have XCode 6.1. Recently, I deleted DerivedData folder in ~/Library/Developer/Xcode folder while XCode was running. After that my workspace did not work - the iOS app would fail to compile and I got linker error saying it cannot find the library projects.
I tried to solve it by removing my the 2 libraries from Embedded Binaries of the app project - and I cannot add them back. Clicking + button under Embedded Binaries in project settings displays workspace projects correctly but selecting and adding my library project does not add them to the list of Embedded Binaries. I have solved the linker error by creating new workspace. The app compiles but how it links the libraries is a mystery to me: They are not in listed Embedded Binaries or Linked Frameworks and Libraries not in the Frameworks search path. There appears to be no link between the app and the libraries it needs (and obviously have as it compiles) except that libraries projects are in the same workspace.
Why I cannot add library projects to Embedded Binaries? Is it normal in XCode 6.1 that dependency projects just compile and gets embedded into an app without being listed or linked anywhere?
This is a summary of my answer to the question Xcode won't add “Embedded binary” after deleting “DerivedData”, see the original question and answer for more context and information:
Remove all framework projects from the workspace
Perform a "clean build" and/or remove the "DerivedData"
Add project back into the workspace
Build the project (possibly optional)
In the General tab of the app target click the + under "Linked Frameworks and Libraries", select the framework.
Build and run in the Simulator (there should be no issues building or running)
Build and run for device (this might cause a crash due to the framework not being correctly linked, ignore this crash)
Click the + under "Embedded Binaries", select the framework. This should add it to the project (possible duplicate under "Linked Frameworks and Libraries")
Repeat for all required frameworks
Once building and running (on device) is confirmed you can remove any duplicate (and/or red) frameworks in the Project Navigator or target General tab
Ok, I ran into the same problem as you. After deleting the derived data, I could not re-link my binaries again. I think the reason is because the derived data is where the binaries are written to and linked against in your project.
What I did to solve was to select my Framework as my build target. After building it, the Framework target turned from red to black. I can see in your screenshot it is red, meaning it has not been compiled into a binary and written on disk.
Once I did this, I was able to re-link the Framework to my Project because there was a reference to it on disk. Hope this helps!
Clean your projects & build your framework first. Thereafter you can embed it.
Here is how I solved the problem:
Build the framwork.
Open the build folder and drag built framework into the app project (so it uses the path to DerivedData).
Add the framework to the list of embedded frameworks.
In the Finder, do a Show Contents on the app's xcodeproj file, then open project.pbxproj in your favorite text editor.
Find the line with the long DerivedData path. Change it so there is no name, the path is the framework name, and source tree is BUILT_PRODUCTS_DIR
Xcode should notice the change and the library in the app project will be black instead of red and will now build and run properly.
I have a very similar issue and fixed it just last night. Decided to come back to this thread and offer my workaround, as rjstelling's solution above did not help my case.
I have a workspace that contains two frameworks and one application. The App was making use of both frameworks happily for a while until I got hit by a mysterious compile eror where it decided that adding a property access to an instance variable called "cube" of a class type found in one of the framework, made access to "_cube" impossible (complaining it was not declared, while it had actually worked previously in a setter method).
Long story short, after a clean, somehow the workspace/app project lost track of the embedded framework of my iOS 8+ project. Removing the embedded framework was the last straw in that line of failure, causing my project to no longer allow be to select any frameworks for embedding.
Reverting the project & workspace to an earlier version did not get rid of the voodoo.
I ended up adding the to-be-embeded framework projects in the main app project (as files) and introduced target dependencies on the frameworks.
I was then able to re-embed the frameworks and link.
As for the _cube thing, I had to specify a getter for the property and #synthesize the property to a different name. I dont have an explanation for this one.
It's probably because your framework is a separate project and not a separate target. Try watching carefully Session 416: Building a Modern Framework at around minutes 34-36. It will show you how to set it up correctly.
This makes it a bit confusing if you wanted to share a framework across multiple projects by the way
I was working on Project in Xcode 6.1. It was working fine and all of sudden it prompted an error 'Restkit/Restkit.h file not found'. I'm getting error after changing Architectures from $(ARCHS_STANDARD_32_BIT) to Standard architectures (armv7,arm64) - $(ARCHS_STANDARD) which is recommended by Apple Check Link
I have tried following approaches :
1.'Cleaning' project and rebuilding
2. Checked for missing framework in Target -> Build Phases
3. Fixed 'Framework Search Path' of Target
4. I have build Restkit XcodeProject and Targets separately. It builds without error.
I was getting below error while submitting to App Store and hence changed architecture to 'Standard architecture'
Why did this occur all of sudden? How to fix it?
Just to be here. There is similar issue in newest Xcode 7+. You can observe "RestKit/RestKit.h file not found" failure on archive build. You could compile and run apps on emulator but archive would fail.
To fix this you need to add one line to "Header Search Paths" in Build Settings:
"$(BUILD_DIR)/../IntermediateBuildFilesPath/Headers"
Be sure to include the surrounding quotes.
You have not properly changed Architecture , if you have done properly than it will show you like this,
Proper Architecture setting:
So again properly change Architecture and try again.
This is your Architecture Setting
I had used third-party static library in project named libNuance.a. It seems that this static library works fine for 32-bit architecture but failed for 64-bit architecture.
I downloaded updated version of libNuance.a library from their official site and changed architecture to Standard architectures (armv7,arm64) - $(ARCHS_STANDARD).
Vola! build succeeded without any error.
First you can try, look for it in project navigator(left side) and delete if it is red.After that add the RestKit again.Be sure when adding check the copy if needed box and packages contains headers.
Also you may try just #import "RestKit.h"
I had solved this in many cases by deleting the contents of DerivedData folder. See the following questions on how to do this:
Can I safely delete contents of Xcode Derived data folder?
How can I safely delete in my ~/Library/Developer/Xcode/DerivedData directory?
If you have Pods configured then and if you have upgraded recently your Xcode, try reinstalling cocoapod and all the reinstall all required pods.
I fixed this issue, to change the Header Search Path
"$(SOURCE_ROOT)/RestKit-RestKit-c19a500/Build"
Note : "RestKit-RestKit-c19a500" this is my RestKit folder name.
I have set up an XCode 5 iOS 7 project for unit tests.
Of course, setting up the unit tests are taking me so long that I'm trying to keep the faith that it's worth it. Struggling for hours over this error:
ld: building for iOS Simulator, but linking against dylib built for MacOSX file
'/Applications/Xcode5-DP5.app/Contents/Developer/Library/Frameworks/XCTest.framework/XCTest'
for architecture i386
Any ideas on how to solve?
Check your Framework Search Paths in your test target settings. These can be corrupted when adding the XCTest Framework.
Adding XCTest to one of my projects prepended a "/" to the paths causing them to not find the correct version.
None of the above answers worked for me. I did find an answer here in a comment left by Tim Macfarlane.
For linker errors looking for a class in your app...
set the “Symbols Hidden by Default” build setting to “NO” in your app
target. This makes all your app classes available to your test target
automatically...
So, that means:
Project Navigator > Select your project
Targets > Select your App (not Tests)
Build Settings > Search for "Symbols Hidden By Default"
"Symbols Hidden By Default" > Change it from "YES" to "NO"
I had the same issue; the problem (for me, at least) was that the FRAMEWORKS_SEARCH_PATHS build setting listed the SDK frameworks folder after the main developer frameworks folder.
The frameworks included with Xcode have three separate builds: one for OS X, one for iOS (device), and a third for the iOS Simulator. The OS X build is in the main developer folder, with the other two being under their respective platform folders. The rub here is that if you don't specify to search the SDK folders first (which are within the platform folders), Xcode (or more correctly, the linker) will find the OS X build first and produce the error you see.
The solution is simple, put:
FRAMEWORK_SEARCH_PATHS = $(SDKROOT)/Developer/Library/Frameworks $(inherited)
in your build settings. If you're putting build settings in the project file (I don't recommend it, but that's another question for another day), it's just named "Framework search paths."
NOTE: Sometimes Xcode's a little slow to catch on; you'll probably need to delete your build folder (better than just a clean) for this to take effect.
Have the same problem after converting tests from SenTestCase to XCTestCase. Reverting framework dirs fixed issue:
"$(SDKROOT)/Developer/Library/Frameworks" (non-recursive)
"$(DEVELOPER_LIBRARY_DIR)/Frameworks" (non-recursive)
So, for me, what I was missing after trying everything else in this post, was:
Other Linker Flags:
-framework XCTest
I'm currently using Xcode 6.0 (with the iOS 8 SDK) so I'm surprised that the "Edit > Refactor > Convert to XCTest..." option doesn't add this automatically.
I was facing problem while adding sentestingkit framework in xcode 5 . These settings worked for resolving linker problem.
I had this problem upon adding another file for tests.
If you do this with (CMD + N) be sure to only target
the Test Bundle (ie. 'AppNameTests').
I guess only these .xctest bundles have access to the
XCTest Framework.
I had the same issue after renaming my Target name and moving things around. It turned out that my tests were part of my Main Target. Make sure that you all your test files belong only to your test target.
Just select a .m file, make sure you have the right pane open.
I had the same problem when tried to build XCTTest-based unit tests with pre-7.0 SDK. When I chose 7.0 as my Base SDK then that kind of link error disappeared.
Had a the same issue but ended up with a slightly different solution.
select XCTest.framework and make sure that only your test folder is checked under Target Membership.
Make sure that the Search Framework Path (FRAMEWORK_SEARCH_PATHS) for the YourProjectTests target includes the path $(SDKROOT)/Developer/Library/Frameworks, and that this one is listed before $(inherited).
In my case, both paths were present, but $(inherited) was the first one.
Credit goes to https://stackoverflow.com/users/181947/brian-clear on Apple Mach-O linker (id) warning : building for MacOSX, but linking against dylib built for iOS