I have created a local copy of the Nimble test framework and I am attempting to add it to the test target of a default, empty, Xcode project. I have added the 'Copy Files', build phase for Nimble.framework in the test target. The framework now magically appears in my project navigator.
After adding Nimble.framework to 'Link Binary With Libraries' I get the linking error; Nimble.framework not found.
A spotlight search of my machine only finds Nimble.framework in the git directories where I created it. Where are the Framework directories that Xcode uses?
My Runpath Search Paths build variable has #executable_path/../Frameworks and #loader_path/../Frameworks. I have added #loader_path/Frameworks to these to be safe but my information sources are probably dated.
Yes, I have clean built and deleted entirely the DerivedData folder many times already trying to figure this out.
Related
I've put libsteam_api.dylib in the project folder. I've dragged it into the 'frameworks' folder in the project, and added it to the target. It shows up in the list of linked libraries
When I build and run, I get a "Library not loaded" error, and libsteam_api.dylib is nowhere to be found in the application bundle.
If I then manually copy the library into the MacOS folder of the bundle alongside the executable, it runs fine, but I don't want to have to keep doing that for every build
How do I get Xcode to include the library alongside the executable?
Add a Copy Files build phase to your target, copying the dylib into the Frameworks folder of the app package.
Just banged my head against this as well. There are two pieces to the solution.
1) In your project target's General settings, add the dylib to the list of "Frameworks, Libraries, and Embedded Content", then set its option to "Embed & Sign".
2) Then, under Build Phases (where it should now appear in the "Embed Libraries" section), set its destination to "Executables". (Steam's dylib wants to live alongside the executable, not in the Frameworks directory.)
I am new to cocoa and mac development. I have written an application which is combination of objective-c using cocoa framework and backend written in C++ library dylib.
I am using xcode 4.6 and have the above two projects Cocoa app and my C++ library. C++ is also my own project.
Now it is time for deployment. I want to make a pkg installer for it.
I could run/debug it in the xcode 4.6 because I had added search library path in the object-c project settings to be the output directory of the C++ project. Therefore it could find the dependency and run without crash.
Now in the Objective-C project tree inside the xcode I see products -> mysoftware.app file. if I find the location of this mysoftware.app file in the finder and run it, it crashes. I open the package contents of this app files and I see contentsfollowing structure
contents\(info.plist, MacOS, pkginfo, resources )
I do not see my C++ library in there, when I run mysoftware.app directly double clicking it crashes as it can not find the dylib I see the stack trace in the report window it can not find dylib, complaning that library not found usr/local/lib/mylib.dylib
I have also manually put the dylib file in the .app within the MacOS where my executable is, hoping that it will find the lib from the same directory, it did not , gave the same message above and looking from the the sane location /usr/local/lib/mylib.dylib
So my question is how do I resolve dependency of .app package for deployment, should I need to put the dylib inside the .app package ? how do I do that and then my next step would be to put this single .app thing in the pkg installer,
Thanks
This is what worked for me:
Drag the dylib into your Frameworks.
Add a Copy Files build phase, destination Frameworks and put the dylib there.
Add a Run Script phase which has the following script:
MYLIBNAME=libmylib.dylib
install_name_tool -change /usr/local/lib/$MYLIBNAME #executable_path/../Frameworks/$MYLIBNAME "$BUILT_PRODUCTS_DIR/$EXECUTABLE_PATH"
That's it. The script tells your app to load the dylib from the right place - otherwise it will complain about not finding the dylib at runtime.
Note that you don't need to change anything in the dylib itself - it could be supplied from elsewhere.
I resolved it so I am putting up this answer to help others who want to do the same.
The dylib has to go in one of the sub folders within the application bundle (i.e. mysoftware.app). Could be MacOS, Frameworks or any sub folder we decide to put it in.
The first step is in the target settings of our dylib, we set the install path to be relative to the app bundle (mysoftware.app), so in Xcode target settings of lib I set it to:
#executable_path/../frameworks
You can also use #rpath (You might want to research on that, I think it is more flexible than #executable_path)
Xcode will change the install name as well for our dylib.
Then in the Objective-C project using our dylib in the Project settings -> Build phases -> Link -> we drag our dylib here from the products node of the dylib project.
In the Objective-C/Cocoa project, the last step is to add a build step named copy files, and it should show a combo box telling you the target folder of the bundle. I set it to frameworks (this will depend on that relative path you choose when setting install path of your dylib) . The second part of the 'Copy Files' build step is to provide the souce file to copy. That's our dylib file that we want to pack in the bundle's Frameworks folder. So drag the dylib file from the products (of your dylib project) to the source file of the build step.
And that's it.
Now when we build the Objective-C or Cocoa project, if our build steps and install_path , etc are correctly configured, it should build fine. After a successfull build of the Cocoa project, go to Products -> mysoftware.app -> Locate in the Finder and when you run it, it should run fine. Since the dependency dylib is in the Frameworks folder of the bundle and correctly linked. You can see the package contents of the bundle to see if the Frameworks folder contains your dylib file.
To my surprise, the path where a dylib is stored has to be part of the dylib. So when a project links to this dylib it will copy the same path in itself, so when we run the Cocoa app which was linked to that dylib, it will look for it at exactly the same path which it copied from inside the dylib and we are responsible for telling the dylib where it exists. In the form of install_path, etc.
There are tools to manually update the dylib's install path stored in the Cocoa project using that dylib. If update the path of an existing bundle using these tools it should be changed in the client of the dylib, not required in the dylib itself.
If we've the code then we can change it in Xcode as instructed above.
otool -L my.dylib for example can be used to see the dylib install path of an existing binary lib
install_name_tool -change can be used to update the install path of existing binary lib
I'm getting the following error:
ld: library not found for -lGoogleAnalytics
clang: error: linker command failed with exit code 1 (use -v to see invokation)
I've spent some time googling but can't find how to fix this problem. I'm new to xcode and this is an existing project that I need to work on.
In my case, the project uses CocoaPods. And some files are missing from my project.
So I install it from CocoaPods: https://cocoapods.org/.
And if the project uses CocoaPods we've to be aware to always open the .xcworkspace folder instead of the .xcodeproj folder in the Xcode.
You need to set the "linker search paths" of the project (for both Debug and Release builds). If this library was in, say, a sibling directory to the project then you can set it like this:
$(PROJECT_DIR)/../GoogleAnalytics/lib
(you want to avoid using an absolute path, instead keep the library directory relative to the project).
All in all, the Xcode cannot find the position of library/header/framework, then you tell Xcode where they are.
set the path that Xcode use to find library/header/framework in Build Settings --> Library/Header/Framework Search Paths.
Say, now it cannot find -lGoogleAnalytics, so you add the directory where -lGoogleAnalytics is to the Library Search Paths.
In my case I had a project with lots of entries in "Build Settings > Other Linker Flags"
I needed to reduce it down to just
$(inherited)
-ObjC
Old settings:
Updated settings:
For me, I open the projectname.xcworkspace file and it all works.
If you have pods installed, make sure to open the workspace folder (white Xcode icon) not the project folder. This resolved the library not found for ... error. Very simple issue but I was stuck on this for a long time.
This worked for me:
Go to build setting -> Linking -> Other Linker Flags -> Remove all other than $(inherited)
Cd ios && pod update
If you are using Pods to include the GoogleAnalytics iOS SDK into your project, it's worth noting that since the 3.0 release your Other Linker Flags needs to include -lGoogleAnalyticsServices not the old -lGoogleAnalytics
If your library file is called libGoogleAnalytics.a you need to put -lGoogleAnalytics so make sure the .a file is named as you'd expect
None of the above worked for me, what did was making sure the Pod file platform :ios, '11.0' matched with the minimum deployment target in the XCODE setting
You can also try to lint with the --use-library option, as cocoapods lint libraries as framework by default since v0.36
The problem might be the following: SVN ignores .a files because of its global config, which means someone didn't commit the libGoogleAnalytics.a to SVN, because it didn't show up in SVN. So now you try to check out the project from SVN which now misses the libGoogleAnalytics.a (since it was ignored and was not committed). Of course the build fails.
You might want to change the global ignore config from SVN to stop ignoring *.a files.
Or just add the one missing libGoogleAnalytics.a file manually to your SVN working copy instead of changing SVNs global ignore config.
Then re-add libGoogleAnalytics.a to your XCode project and commit it to SVN.
In XCode 10.1, I had to set "Library Search Paths" to something like $(PROJECT_DIR)/.../path/to/your/library
For me it was a silly thing: my mac uploaded the file into iCloud, and that is why Xcode did not find it.
If you turn off the automatic upload, it wont happen again.
Xcode 4 is throwing me a warning about directory not found for option '-L/Users/t2wu/Documents/blah blah'. Yes it shouldn't be found because I removed it. I remove the directory and I also removed the directory setting in both the target and the project library search path. I also remove the .a file which I was linking before from the "Link binaries with Libraries". It compiles fine, it just gives me the warning. Why is it still having the -L flag?
Check the Build settings tab and make sure that the "Library search paths" option is empty.
At last resort, fire up Terminal and cd to the app project directory (appname.xcodeproj) and do a fgrep for the erroneous search path. I've found some of these lurking in the project.pbxproj file; ended up editing the file manually to get rid of them. (Of course you should make a copy of the file before doing so, in case you trash the project file.)
It'd also be worthwhile to do a "clean" on the project. How to Empty Caches and Clean All Targets Xcode 4.
I had the same issue in my project, it contains multiple custom framework created by me and the project. My issue is resolved by removing 'Framework search Paths' and 'Library Search Paths' from the target which has this issue.
In my case in targets -> build settings I removed searchpaths for which errors occured. Then removed libraries from project and added them again.
You may need to clear the Search Paths for the Tests target as well as the main project. This had me stumped for a little while.
I checked the library search path
I went to Build settings -> Search Paths change the "Framework Search Paths" to $(inherited)...that solved my problem
Sometimes, this error occurs if you open Project.xcodeprojinstead of Project.xcworkspace. Check your project directory and make sure to open Project.xcworkspace.
I'm consolidating my Xcode/TextMate setup and is interested in where you put your build dir.
Some years ago I started out having the build dir in the same dir as my xcodeproj file.
However it became a mess when my project became a multi project with a applications and frameworks and tests, so I started using ../build as the build dir, so that all the sub projects used the same dir. However Spotlight is indexing this build dir and TextMate's global find is unusable when there is a build dir in the project.
I'm thinking either using ~/.build or /build as Xcode's build dir.
What build dir do you use and why?
If you let Xcode create the build directory then it shouldn't get indexed by Spotlight (Xcode sets an extended attribute on the directory specifically to make this happen). If it's a build directory from an old project that been upgraded, or a build directory that you created manually, then this won't be the case and it will get indexed. You can either add this attribute manually if it's missing, or perhaps delete the build directory and let Xcode re-create it. Once you have this sorted out you should be good to go with your common build folder scheme.
The extended attribute is com.apple.XcodeGenerated.