I have created a static library in XCode that requires several dynamic libraries (e.g. libsqlite3.0.dylib). I can create an application that is dependent upon my static library using cross-project references in XCode, but it seems that I have to manually add all of the required dynamic libraries to each of my application projects to get them to link.
Is there any way to configure a static library project in XCode so that dependent applications will automatically link against whatever dynamic libraries it requires?
I tried adding the dynamic libraries to the list of Frameworks in my static library project, but this seemed to have no effect.
Yes -- you will need to add the libraries to the applications. A static library -- a .a -- is just an archive of .o files with a minimal bit of internal symbol resolution. The full symbol resolution doesn't happen until you link it into an application (or framework).
(Are you using sqlite3 directly? If so, why not use Core Data? There are reasons, but not nearly as often as people thing...)
Related
I understand that plug-ins are components that are tasked with a specific function and loaded for use by an application.
Shared object libraries (.so) in linux and .dlls in windows are libraries that are loaded at run-time by an application.
I want to understand what if .dll / .so are always plug-ins. Are all plug-ins .dll / .sos?
Actually, .dll's and .so's are dynamic libraries. There are also other type libraries named static libraries. In Linux, their extension is .a.
Programmers tend to use libraries for maintaining their code easily. Also, if the library will be shared more than one application, shared library is chosen because of main memory usage.
You can apply this logic for a structure which contains plug-ins. If the code piece will be used only by your application's single process, you can use static library as your plug-in. However, if the code will be shared by multiple processes, you should use shared libraries, even if these process are instances of the same application.
When you use shared libraries as plug-ins, you must not include library as known methods and you must not link your executable directly to the library. Instead you must use libdl. Have a look at here and look for the dynamic loading.
I want to build two apps, one optimized for iphone and one for ipad.
both of these applications invoke server API calls and would share the same code for model objects, so I would like to share this code between my iphone and ipad projects.
I am using xCode 4, with a concept of workspace (which is supposed to allow sharing of code between projects) but I was wondering if I need to create another project for just the shared code.
Has anyone done this and care to share the best practices?
I prefer to share code across projects, be it for iPhone/iPad reuse or any other sharing scenario by leveraging a Static Library Project to house shared code, and used as a Target Dependency in all projects that consume it. In a bit more detail...
You can create a new Xcode Project with a Cocoa Touch Static Library template. This project can house all of the shared code between projects. Then, in any app in which you want to use the static library, you can add a project reference to the static library project by dragging the static lib project into the client project. In this client project, it's a good idea to add the static library as a Target Dependency build phase of the client project. This forces the shared library to be re-built anytime the client project is built. Then, you'll add the static library product to the "Link Binary With Libraries" build phase of the client project.
And, as one final caveat, you also need to tell the client project where the headers for the static library live. This is a result of static libs not containing their own headers like a Cocoa Framework on the Mac does. To do so, just find the "Header Search Path" build setting in the client project, and add the path to the static library headers. I've found it most useful to reference the ones produced by Xcode and placed in Derived Data (if you have Xcode configured to do so).
If you are going to build two separate applications, then you need to create one workspace with two iOS application projects and one static library project. The static library should contain all of your shared code, and the library should be included by both of your iOS application projects.
Has anyone had any success in finding a reliable, generalised solution for managing dependencies for iPhone projects? I'm looking to split my iPhone applications up into reusable components and then pull them into projects that require them. I guess I'm looking for a Maven-esque workflow but for Xcode/iPhone projects. I've tried a number of things so far such as:
I've created a Maven plugin for iPhone applications which automates the building and signing of the applications but I constantly feel like I'm fighting against Maven to get this to work and it is altogether pretty messy. I'd rather not use this unless there are no other options.
I have also tried using static libraries to package the code up to re use but the problem with this is that I'd also like to include reusable XIBs and images in my projects and these cannot be included in the static library for redistribution. They are great for code but I'd like to have one system that does everything rather than different dependency management systems for different types of dependency.
At the moment I've settled on using the version control system to do my dependencies for me. In this case I'm using SVN externals to load the dependencies into the workspace when I checkout the project.
Does anyone have any ideas as to what I could do?
Update
I'm now using CocoaPods to perform this task.
The way I've done it in the past is as follows:
Static Library for shared code
Bundle for Images / Data Files / Etc (Non Code)
By doing this, you only ever have to worry about updating the project that manages your static library / bundle and not the applications that use them.
The key thing to creating a bundle, is that Bundles are not listed under iOS when adding a new target to a project. Instead they are listed under Mac OS X. Don't worry, it works great.
Once you've created your Bundle and Static Library targets, you'll need to get those into your application:
Add the Static Library under Link Binary With Libraries (Xcode 4)
Add the Bundle under Copy Bundle Resources (Xcode 4)
The final thing to keep in mind is that when you want to load resources from the newly created bundle you need to do something like the following if you were going to load an image:
UIImage *myImage = [UIImage imageNamed:#"YourBundle.bundle/MyImage.png"];
With Static Libraries, you can distribute the XIB's/Images/Strings in a Bundle Folder which can be imported easily. It is the easiest approach I've found for distributing dependencies short of distributing the actual Code/Xcode Project
Each C/C++ library has some amount of headers that should be used with that library. And if you're use more than 1-2 libraries, custom header paths is kind of headache.
So I thought: is there a way to compile C libraries as frameworks. Static library + headers + versioning.
I found in XCode template for Cocoa framework but nothing about iPhone framework building. This simple step could allow developers to build and share between each other frameworks with some interesting code.
Also it would be great to use libpng, libjpeg and other libraries packaged as frameworks.
I won't use dynamic libraries in those frameworks. Only static version will be present.
I combined techniques I found here and here into my open source library here (NOTE - I have since removed the relevant scripts from this project. I have updated the link to point to the last revision that included these techniques.). Think that's basically the solution you're looking for.
Basically, it has a target that will build a fat static library (lipo builds for arm6, arm7 and i386). It has another target that takes that library and builds it into a framework.
There's no reason you can't use the same techniques for a C project. In fact I've started work on porting C the VTD XML parser to an Objective C framework using the same techniques.
Frameworks are basically just bundles of dynamic/shared libraries. Since this is not allowed in the App Store, you have to build static libraries and link them with your App's executable at compile time.
However, to ease the pain a little, you can have a Xcode project for each library and compile each library into a static lib. Another way would be to put all required source files into the main Xcode project and configure it appropriately so it all builds at once (I did this with small libraries like Minizip, for instance).
Hope that helps.
the problem you are trying to make already exists - it's called DLL hell
Best way is to stick with plain old static libraries when making small apps and organizing source/headers structure
I'm writing a static library for the iPhone and I'm wondering if what I'm doing is recommended or if I should take a different approach.
The static library I'm writing is dependant on libxml2. libxml2 has a dynamic library (dylib) and a static library (a). I've tried two approaches.
Approach one - When I attempt to link against the static library by adding "-lxml2" to "Other linker flags" the build fails with the following message:
/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/libtool: file: -lxml2 is not an object file (not allowed in a library)
Approach two - I can successfully link against the dynamic library from my static library but I'm not sure if this is allowed (or the proper approach) on the iPhone. Even though I'm building a static library, does Apple allow static libraries that link against dynamic libraries? I'm still learning about static libraries, but from my understanding the code from the dylib would be combined with my code to make one library, thus linking against the dylib shouldn't be an issue.
To summarize:
mylibrary.a -> libxml2.a [Doesn't work]
mylibrary.a -> libxml2.dylib [Builds, but is this correct and acceptable?]
libxml2.dylib is available in the SDK. The right way is to double-click the target node/app in Xcode and then under General click the + under "Linked Libraries"...you should find libxml2.dylib in that list.
0:42 in this Screencast you can see how CoreGraphics is added to a project.
You can not statically link libraries into other static libraries. This is why frameworks and libraries that depend on other static libraries asks the consumer to add them manually to their Link Binary With Libraries build phase or Other Linker Flags build setting.
Apple doesn't allow you to link frameworks and/or libraries other than that provided with the SDK.
Marco