I created a static library which internally contains another static library (X) inside "Link Binary With Libraries" folder. But when I export my library to a sample project and try to compile it fails to locate the X library path. I am adding "." in the "Library search path" build parameter while building my static library.
What is that I am missing here?
If I understood your issue correctly, then it is less a linker-search-path problem but more a conceptual problem.
I see two options for solving the issue:
The common and straight-forward solution;
add both static library projects into the project of your app
expand the included projects
expand the Targets of your app-project
expand the "Link Binary With Libraries"-Entry
drag the product files of your library projects (actual libraries) down into that "Link Binary With Libraries"-Entry
include the header-path to both of your library-projects within your USER_HEADER_SEARCH_PATHS build settings
The next approach is rather unconventional and in most cases just not worth the extra mile. Here comes some explanation before going into the details.
The concept of a static library basically is a bunch of object-files stuffed into one single file (archive). Linking a static library against another static library is rather uncommon - well, to spell it out correctly, impossible.
...but then again, nothing is impossible when it comes to coding ;)...
The wrapper-library solution;
use ar to extract all object files from all the libraries you want to combine
use ar to combine all those object files into one big, new library
ALong with setting up Header Search Path , Try setting up the Other Linkers Flag too..
Go to “Other Linker Flags” under the “Linker” section, and add “-ObjC” and “-all_load” to the list of flags
Hope that works for you,
Related
I have a C++ library that is full of warts and weird features, and I want to make it much easier to use (and reuse) in a Swift project. So I intend to wrap this C++ library in some Swift code, then make it available as a Cocoa Touch framework.
I've added both my (fat) .a file and the required .h files to my project, then added the .a to the "Link Binary with Libraries" section of Build Phases, and added the main .h file to the Project section of the Headers build phase. But the build fails with:
Library not found for -lMyLib
I'm obviously missing something here - I'm guessing maybe I need to adjust the Framework Search Path and/or Header Search Path? Or am I missing something more fundamental? My desired end result is a .framework another developer can pull into their Swift project without having to do any other build setting tweaks.
You're probably looking for "Library Search Paths" (LIBRARY_SEARCH_PATHS). You may need to add to "Header Search Paths (HEADER_SEARCH_PATHS) as well, depending on your setup. In this case, you shouldn't have to add anything to the Framework search paths, since you are not dealing with a Framework.
(As an aside, you are likely going to find that you have to wrap your C++ library in Objective-C++ code to expose the functionality to Swift.)
What are the different possibilities when this error can occur?
What are the things one should look out for, in order to get rid of this?
What if XYZ is an static library directly added to project?
It means you are trying to link to a library which is not found by the system. In your case that appears to be a simple static library. You should check the following:
Look for the corresponding item in red among your project files, with special attention to the Frameworks group (that's where people normally put libraries). If you find one, fix the path or just remove and re-add the library manually.
Repeat this in the Link Binary with Libraries entry under the Build Phases tab in the project/target settings.
Check the Library Search Paths entry in the Build Settings tab in project/target settings. Make sure the path to your libXYZ.a file is listed there.
I plan to use AQGridView which I found on github, it says:
"This project compiles to a static library which you can include, or you can just reference the source files directly. Note that there are some resources to copy into your project for the tableview-style selection backgrounds."
But I have no idea what does this means, can anyone one tell me clearly the steps how can I add this to my project?
Thanks
After compiling the project, you'll get a dylib-file (you may already have it?).
Now, drag the dylib-file to your app-Xcode-project.
Go to your target settings and add the includes-folder to your Header Search Paths so that you can use it's public classes.
Now make sure it's in your target's 'Link with library'-list.
Compile!
How do I reference another project which has code I wish to leverage in XCode 4. In particular I'm trying to make use of the NSDate extensions from here.
Some notes:
I was assuming I should probably reference rather than trying build a framework
I tried copying the existing "Hello World" xcode project file across into my project, however this didn't seem to work
Do I need to create a new "Target" based on "coco touch static library" option?
Then would I need to Edit the current Product Scheme so that when I build the new target would build
What do I need to do on my project side exactly - should going Add Files, and choosing the extensions Xcode Project File be enough?
thanks
I was assuming I should probably reference rather than trying build a framework
yes, reference and link with it, unless you need only a bit of it. at this stage, separating the bits you want may be an advanced topic (depends on the lib's layout/depends as well). you should prefer to reference and link because it will normally minimize your maintenance time, especially if you use it in multiple projects.
I tried copying the existing "Hello World" xcode project file across into my project, however this didn't seem to work
you don't create a project, you add the library's xcode project to your app or library, set the lib as a dependency, add the library to your search paths if needed, then link with the library.
Do I need to create a new "Target" based on "coco touch static library" option?
no
Then would I need to Edit the current Product Scheme so that when I build the new target would build
no. you configure it as a dependency. you may need to alter the lib's build settings if there is a major conflict, which the linker or compiler would point out.
What do I need to do on my project side exactly - should going Add Files, and choosing the extensions Xcode Project File be enough?
start with the process outlined above.
There is no reason to bring in an actually project. Either you can bring in the source files themselves and you could even use the same exact files instead of copying them if you want. However, if you have more than just a few files, and you don't think you will be changing the code much, then creating a static library would probably be the best option.
I have 2 projects and I want to use in the first project, a class (i.e. view controller) of the second. Instead of importing all the files of the second project in the first one, is there a way to link it like a framework or library?
I tried the following unsuccessfully:
Dragged-dropped SecondProject.xcodeproj and checked SecondProject.app as a target
Added it as a dependency project in the first project dependencies
Pointed to the header files by adding in the "Header Search Paths" a path pointing to the second project which I copied in a subfolder of the first project.
When I include "SecondProjectViewController.h" I get no errors but when I try to instantiate it I get the "OBJ C referenced from" error.
Any help is deeply needed and appreciated! =)
F.
As an experienced developer I would suggest not sharing code this way across projects. The simple reason is that changes in one project will then directly effect other projects, often rendering them un-compilable. For example, if you share a controller class and decide to implement a change with a new import, then any project that uses that class will be broken until you open then in xcode and ensure that the imported class is available.
A better method is to compile your first project as a static library or framework. I'd also recommend ensuring that it is version some way. For example, in my projects I create static frameworks and store them in a directory called "v0.0.1", "v0.0.2" etc.
The framework can then be dragged and dropped into a second project to use it. The second project then refers to it via the directory path. The advantage of doing this is that if I then change the first project, the second one if not effected by the changes until I choose to update the frameworks path.
Sharing files between projects will work for small cases, that being 2 or 4 projects, but once you have more than that it rapidly becomes un-manageable.
You have only a few steps to go:
4) in First project, click the disclosure triangle in the Groups and Files section for the Second Project reference. this will display the targets of Second Project.
5) Drag the target reference (e.g., static library) from Second Project to the target in First Project's link phase.
That should clear up all the linker errors for the symbols which exist in Second Project's library. Of course, you'll have to remove those sources (based in second Second) which are compiled and linked from First.
Managing static libraries for huge codebases is dead easy this way (although I prefer the build up to the minute (as well as several build variants), and don't reference archived binaries as Derek does). Learning to minimize changes which break builds takes time to learn. dynamic libraries are a bit different - depending on their distribution, you may want to version (as Derek outlined). It's good to share, but you should put the shared exported symbols in a library, which is a dependency of both apps. Just be careful not to add too much unnecessary objc symbols to the library - objc symbols and their references cannot be stripped from the final executable and they will cause runtime collisions if they appear in two images (dylib, app, static lib) within the same process.
You can add the view controller's files to your 1st project regardless of where they are on disk -- the project will make a reference to their location.