I'm building a static library to be distributed to other iOS developers and having some trouble configuring the linker to allow the static library to be used in another app. I have used this guide to create a MyStaticLibrary.framework bundle containing the lib itself, and other assets such as images. This builds successfully and uses cocoapods to source the required dependencies (AFNetworking, etc.). So far, so good.
But when I import MyStaticLibrary.framework into a new Xcode project to test build an app with the library, I get tons of linker errors (Undefined symbols for architecture i386, _OBJC_CLASS_$_CLASSNAME) indicating that I'm doing something very wrong here.
So my question is, how can I build MyStaticLibrary.framework with the dependencies sourced from cocoapods, such that I can provide a 3rd party with just my framework file and allow them access to all functions specified in the public headers?
Any libraries you include using CocoaPods will not be compiled into your framework by default - they're meant to be external dependencies that are not part of your actual product. However, according to their FAQ, they support a mode where you can download pods and not have them linked to your project. From their FAQ:
Note that CocoaPods itself does not require the use of a workspace. If
you prefer to use sub-projects, you can do so by running pod install
--no-integrate, which will leave integration into your project up to you as you see fit.
To include external dependencies in your compiled binary:
For code: Instead of using cocoapods, check out the repositories you want to include and copy the source files into your project -- this will ensure they are compiled with the rest of your code
For static libraries (i.e. .a files), in your framework's Link Binary With Libraries build phase, make sure to include all the ones you would like to compile. You should also make sure the associated header files are included in Copy Headers build phase, with the appropriate visibility.
Note When bundling third party libraries in this way, you run the risk of conflicting with the projects that are integrating your framework. For example, let's say you are using a lib called SOSomeView, and you choose to compile that in with your framework. Now, if the app you are integrating with also includes SOSomeView, you will get a compile-time error that the class is declared twice. To fix this issue, you should re-namespace any external dependencies you want to hardcode into your framework (i.e. rename the class to XXSOSomeView).
I don't know how to solve that problem if you are compiling static libraries in with your framework.
Related
I am just trying to integrate SDL2_mixer in a small app of mine. SDL2_mixer comes with a bunch of external modules provided as DLLs but with no import libs accompanying them. Now I am wondering how I should (dynamically) link them into my app when I cannot tell the compiler to create the required dynamic link info because I have no way to tell it about the DLL and its interface. Is there a way to accomplish that?
I was even going so far as to download the source code of the required modules (ogg, vorbis, flac, mpg123) to build the dlls myself and get the libs, but mpg123 stopped me dead in the tracks because it is totally porting unfriendly (no up to date make files for Windows, so no config.h etc. header files, hence missing type declarations and what not).
Btw, SDL2_mixer.dll (from the binaries package) doesn't come with an import lib either.
I have two separate git repositories that I am not sure how to best bring together using cmake. I would like a solution that is cross platform.
I have a C++ library project which produces a static library (and C++ headers). This project has its own cmake which will produce a static library. I haven't yet written an install step in the cmake.
I have a UI (Qt) project which visualizes the product of this library. This also is based on cmake and should be using the library; in fact, it does not make sense without the library.
What is the best practice for a situation such as this? I could imagine a few things:
The library is a git submodule of the UI project and the cmake of the UI uses add_subdirectory()
The UI build expects the user to have built and installed (to the system) the static library & headers
The UI build has a hard coded path (or ENV var) to the cmake of the library (or something like LibraryConfig.cmake, but I'm not familiar enough with this yet)
My end goal is that the user should be able to pull, build, and use the library in their own projects, but if in the future they feel necessary, they can grab the visualization tool additionally and use it with the library. Also, people who are not comfortable with using the library themselves might just want to clone the visualization tool repo and build & use it.
This question will be easy for Xcode pros but for a MonoTouch developer it seems to be impossible to resolve. :-)
I'm using Xcode 4.5 and I want to target iOS 5.1 and above and iOS Simulator 5.1 and above.
I have a a library project here and it is coming with a prebuilt binary named "DemoLib" (no extension and it is 11MB in size). The library is a fat lib for Simulator and iOS 5.1+.
I can use that library without any problem.
However if I try to build the library myself, I end up with a "DemoLib.a" file (notice the extension and the size of 30MB). How can I get the same build result? What is a .a file compared to the file without extension?
I tried to build the project "for running", and "for archiving" in Xcode. Both results in the same 30MB .a file.
I was expecting some dropdown in Xcode where one could select "DEBUG" or "RELEASE" build and the latter one would create the smaller lib.
Of course I could never tell without seeing the framework's project file. Having said that, there is an excellent guide to creating and compiling iOS frameworks here: https://github.com/jverkoey/iOS-Framework
Using the above guide, you should be able to recreate your framework's project from scratch, add the files you have to it, and properly compile it.
Hope this helps! :)
Did it come with a Makefile? Create a new target, set the build settings of the target to what's in the Makefile, then set your project to depend on that new target.
A file with the .a is a static library, which means it depends on nothing external and all the code it needs is compiled inside it. I think no extension generally implies dynamic library, which means it'll depend on some dependencies being present on your system to link against. Maybe that's why the .a is so much bigger. I think Xcode will build static by default because iOS does not allow the use of dynamic libraries.
The dropdown for what to build is in your scheme. Command+shift+< to view your scheme. Within the scheme you can edit which environment each method of building will use.
I'm developing ios B2B app and I have several questions regarding app modularization.
Firstly i need to understand main difference between bundles and frameworks. When to use bundles and when frameworks.
Another question is. Is it possible for bundle to contain a .framework inside in it and vice versa.
Is it possible to create a plugins for ios app and load them dynamically, if yes then what it should be? bundle framework or library?
Is it possible for library to contain a resource files ?
Is it possible to create a resource bundle and dynamic library and then load them dynamically at runtime.
Is it possible to create a plugins for ios app and load them
dynamically, if yes then what it should be? bundle framework or
library?
No
Is it possible for library to contain a resource files ?
No
Is it possible to create a resource bundle and dynamic library and
then load them dynamically at runtime.
No
A Bundle is a type of Directory, a folder. A Framework is a bundle. So is an Application and so is a Plugin.
A Static Library is a single file code archive you can compile into your app at build time
A Dynamic Library is a single file code archive you can load at Runtime
A Framework is a Dynamic library in a Bundle with other things
A Plugin is a Dynamic library in a Bundle with other things
The Xcode build option 'Bundle' means 'Place the compiled Dynamic Library in a Bundle' - this is what you do when you want to create a Plugin.
Static libraries are the only option for modularising your code on iOS.
On the desktop..
Typically a Framework is for sharing code and resources between multiple apps. You want your app to behave as though the code was actually compiled into it. You want loading to happen transparently and you don't want to do anything special to use the methods, functions, etc. contained in it.
A Plugin (a Bundle containing compiled code and resources) is for optional, dynamically loaded code, e.g. a software extension that you can choose to load or not. You want to carefully architect your app so that it isn't dependent on the Plugin but acquires new behaviour if you manually locate and load it at Runtime.
A Framework and a Plugin are very similar, but a Framework has a strict file layout to facilitate locating and loading code and resources. With a plugin, these jobs are your responsibility so you can structure the Bundle contents however you want.
Because loading code is so easy in Cocoa on OSX (but not iOS) Frameworks can contain Plugins which contain Frameworks which contain more Frameworks, etc.
On iOS some people put Static Libraries in Bundles with resources and call them Frameworks. This has none of the benefits and all of the drawbacks of a real framework.
I'm creating a modular open-source library. Let's say the project has 15 .m files in it.
Should I (1) release it like the Venmo iOS SDK (Cocoa Touch Static Library) or (2) release it like JSONKit (just the source code)?
Releasing as source code means you, and your developers, don't have problems when a new architecture comes out. A static library built as armv6 wouldn't work with the latest Xcode today.
One caveat with source code releases, since you don't know what build settings the project it's added to will have, you'll need to do extra work to make sure it builds without warnings as best you can, even for pedantic warnings.
I prefer frameworks over static libs. Its easier to ship resources in the framework bundle if you eventually need to and there no cost to dynamic linking. If its pure C and the libraries dependencies are guaranteed to be there then it might be ok. But in general I try to avoid static linking unless I know the target OS has the exact dependencies for that binary at deployment time.
Its much easier to load a dynamic library with the endpoints you need at runtime (which were compiled for that exact platform but have the same external interface) than it is to fail with a static lib that was compiled directly to external dependencies which dont exist on the target platform.
Maybe Im crazy but this is what Ive always done in C, C++ or obj C. Just my opinion.
http://en.wikipedia.org/wiki/Static_library