I developed a Cocoa touch framework and am having problems with third party static framework classes which are embedded inside of it.
The problem is symbol collisions when consumer projects use my framework and also import the third party static framework which my framework uses.
I eventually want to remove these classes from my framework since they are conflicting with host project classes (they use same third party framework) and somehow tell my framework to rely on main project third party framework (I will instruct devs to import the framework),
Or alternatively I will add a prefix to these classes so that when hosting projects embed my framework and use the same third party framework as my own framework it won't get a symbol collisions
Any help or direction will be welcomed!
CocoaPods can help you to resolve the problem with duplicate symbols.
Below I provided detailed explanations for how to make it happen:
Definitions
Let's make some definitions for simpler explanations:
MyFramework - framework that you are developing.
MyApplication - application that uses MyFramework.
OtherFramework - third-party framework that is used in MyFramework and MyApplication.
Problem
As I understand the problem is that Xcode fails to build with "duplicated symbols" error in OtherFramework.
Solution
Here are conditions that you need satisfy to fix that problem:
1) MyFramework has to refer to OtherFramework by CocoaPods:
// MyFramework Podfile
use_frameworks!
pod "OtherFramework"
2) MyApplication has to refer to OtherFramework by CocoaPods:
// MyApplication Podfile
use_frameworks!
pod "OtherFramework"
3) MyApplication can use any mechanism to refer to MyFramework (by CocoaPods or by Drag&Drop framework to project).
4) OtherFramework has to be built with CocoaPods.
If it's not built with CocoaPods yet, you can make it yourself.
For this goal you need to create OtherFramework.podspec and optionally submit it to CocoaPods private repository. It doesn't matter if you have source files or just OtherFramework.framework bundle. More details for building CocoaPod here.
TL;DR
Using dynamic frameworks, you should not have to care much about it, as the linker uses a sensible default behaviour. If you really want to do what you ask, you could instruct the linker to do so, at the risk of failure at run-time. See towards the end of the answer for an explanation.
In general, regarding static linking
This is another version of the classic "dependency hell" problem. Theoretically, there are two solutions when linking object files statically:
State your dependency and let the user of your framework solve it in their build system. Some ideas:
External systems such as CocoaPods and Carthage will help you at the downside of forcing constraints onto your user's build system (i.e. the user might not use CocoaPods).
Include the dependency and the header files for it, instructing your users not use your provided version of that dependency. The downside is of course that your user cannot switch the implementation should they need to.
(Maybe the easiest). Build two versions of your framework, one with the dependency library not linked in. The user can then choose wheter to use your provided version or their own. The downside is that there is no good way of determining if their version will be compatible with your code.
Avoid leaking your dependency and encapsulate it within your framework, at the expense of larger code size. This is usually my path of preference these days now that code size is not a real problem even on mobile devices. Methods include:
Include the dependency as source files in your project. Use #define macros to rename the symbols (or using only static symbols).
Building your dependency from source, renaming the symbols in a code pre-build (or one off) step.
Building everything as you were, then renaming the "internal" symbols in the built library. This could potentially cause bugs, especially since swift/obj-c have dynamic aspects. See this question, for example.
This post discusses some of the pros and cons of the different alternatives.
When using dynamic frameworks
If you are building a dynamic framework, best practice is to do "2." above. Specifically, linking dynamically will prevent the duplicate symbol problem, as your library can link to its version of the third party library regardless of the library any client uses.
Here is a simple example (using C for simplicity, but should apply to Swift, ObjC, C++ or anything linked using ld):
Note also that I assume your third party library is written in C/objC/C++, since Swift classes can (AFAIK) not live in static libraries.
myapp.c
#include <stdio.h>
void main() {
printf("Hello from app\n");
third_party_func();
my_dylib_func();
}
mylib.c
#include <stdio.h>
void my_dylib_func() {
printf("Now in dylib\n");
third_party_func();
printf("Now exiting dylib\n");
}
thirdparty_v1.c
#include <stdio.h>
void third_party_func() {
printf("Third party func, v1\n");
}
thirdparty_v2.c
#include <stdio.h>
void third_party_func() {
printf("Third party func, v2\n");
}
Now, let's first compile the files:
$ clang -c *.c
$ ls *.o
myapp.o mylib.o thirdparty_v1.o thirdparty_v2.o
Next, generate the static and dynamic libraries
$ ar -rcs libmystatic.a mylib.o thirdparty_v1.o
$ ld -dylib mylib.o thirdparty_v1.o -lc -o libmydynamic.dylib
$ ls libmy* | xargs file
libmydynamic.dylib: Mach-O 64-bit dynamically linked shared library x86_64
libmystatic.a: current ar archive random library
Now, if we compile statically using the (implicitly) provided implementation:
clang -omyapp myapp.o -L. -lmystatic thirdparty_v2.o && ./myapp
Hello from app
Third party func, v1
Now in dylib
Third party func, v1
Now exiting dylib
Now, this was quite surprising to me, as I was expecting a "duplicate symbol" error. It turns out, ld on OSX silently replaces the symbols, causing the user's app to replace the symbols in my library. The reason is documented in the ld manpage:
ld will only pull .o files out of a static library if needed to resolve some symbol reference
This would correspond to point 1. above. (On a side note, running the above example on Linux sure gives a "duplicate symbol" error).
Now, let's link dynamically as in your example:
clang -omyapp myapp.o -L. -lmydynamic thirdparty_v2.o && ./myapp
Hello from app
Third party func, v2
Now in dylib
Third party func, v1
Now exiting dylib
As you can see, your dynamic library now refer to its version (v1) of the static library, while the app itself will use the other (v2) version. This is probably what you want, and this is the default. The reason is of course that there are now two binaries, each with its own set of symbols. If we inspect the .dylib, we can see that it still exports the third party library:
$ nm libmydynamic.dylib
0000000000000ec0 T _my_dylib_func
U _printf
0000000000000f00 T _third_party_func
U dyld_stub_binder
And sure, if we don't link to the static library in our app, the linker will find the symbol in the .dylib:
$ clang -omyapp myapp.o -L. -lmydynamic && ./myapp
Hello from app
Third party func, v1
Now in dylib
Third party func, v1
Now exiting dylib
Now, if we don't want to expose to the app that we use some static library, we could hide it by not exporting its symbols (hide it as in not letting the app accidentally reference it, not hiding it truly):
$ ld -dylib mylib.o -unexported_symbol '_third_party_*' thirdparty_v1.o -lc -o libmydynamic_no3p.dylib
$ nm -A libmydyn*
...
libmydynamic.dylib: 0000000000000f00 T _third_party_func
libmydynamic_no3p.dylib: 0000000000000f00 t _third_party_func
(A capital T means the symbol is public, a lowercase t means the symbol is private).
Let's try the last example again:
$ clang -omyapp myapp.o -L. -lmydynamic_no3p && ./myapp
Undefined symbols for architecture x86_64:
"_third_party_func", referenced from:
_main in myapp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Now we have successfully hidden our third party static framework to client apps. Note that, again, normally you won't have to care.
What about if you really want 1. in dynamic frameworks
For example, your lib might need the exact version of the third party library that your client provides.
There is a linker flag for that too, of course: -undefined dynamic_lookup.
$ ld -dylib mylib.o -undefined dynamic -lc -o libmydynamic_undef.dylib
$ clang -omyapp myapp.o -L. -lmydynamic_undef thirdparty_v2.o && ./myapp
Hello from app
Third party func, v2
Now in dylib
Third party func, v2
Now exiting dylib
The downside is of course that it would fail at run-time if your client fails to include the static library.
You can always use classes from framework like this:
import Alamofire
let request = Alamofire.Request(...)
And if you have Request class in your own framework, you can use it in the same way:
import YourFramework
let request = YourFramework.Request(...)
There there would not be any conflicts.
I had a similar issue before, but I was using Objective-C third party framework. The problem is solved by using the bridging header to specifically import the framework drag and drop to the consumer project, and leave your framework sort of capsulated. It's just my experience so it might not apply to your case but might as well share it here just in case it helps.
I'm creating an iOS static library, using cocoa pods, including AFNetworking. I'm building from a workspace, the standard cocoa pods way. I want the output library to contain everything from AFNetworking, so I included libAFNetworking.a in the Link Binary With Libraries step for the target (although the library names are in red?). Anyway, I cannot successfully use the resulting library in another project - I get undefined symbols on, for instance, _OBJC_CLASS_$_AFHTTPRequestOperationManager.
If I run
nm -g libMyLibraryBlahBlah.a | grep _AFHTTPRequestOperationManager
I get
U _OBJC_CLASS_$_AFHTTPRequestOperationManager
0000000000008760 S _OBJC_CLASS_$_AFHTTPRequestOperationManager
0000000000008d30 S _OBJC_IVAR_$_AFHTTPRequestOperationManager._baseURL
etc
So _OBJC_CLASS_$_AFHTTPRequestOperationManager is both a symbol and Undefined? How do I make it NOT Undefined?
I am developing a library .a file in Which i am using AFNetworking classes ... This library does also include one .framework which also using the AFNetworking classes (Adding this framework is optional)
Due to this I am getting following errors
duplicate symbol _OBJC_IVAR_$_AFHTTPRequestOperation._responseSerializer in:
.../KonySDK.framework/KonySDK(AFHTTPRequestOperation.o)
.../Core.a(AFHTTPRequestOperation.o)
Options i have already considered is removing AF***.o from one of the file lipo -thin and ar -d -sv commands
Using this Link
But this library is configurable from server and adding that particular .framework is optional.
My question is ... Is there any otherway by which i can resolve this issue ? ALso i can would rather not prefer to remove .m files of AFNetworking from my library source as the entire process of generating library is fully automatic and configurable in many ways
I have also tried to resolve this by removing -all_load from other linker flags but this resulted in crash as categories of some classes are not loaded due to this.
You will get the duplicate symbol linker error whenever you have included a binary version of a class. The way to get rid of it is to remove the superfluous object.
For building your library you only need the .h files of AFNetworking because those tell the compiler which classes and methods are available. You do not need to compile the AFNetworking source code because a .a file is essentially a collection of .o files which each contain the compiled versions of .m files.
Libraries are not linked
Only apps get linked and therefore need to have the symbols/objects present. i.e. if you provide your library without AFNetworking compiled in, then the developer using it needs to add AFNetworking via library, framework or cocoapod.
I'm working on an iPhone app with Monotouch. In my app, I have to use a static library provided by 3rd party. This library is for Xcode and written in Objective-C. I bound it with Monotouch using Binding Project Template. When I add the resulting dll to my project it compiles fine, but when I use a class from the library it fails to compile with the following error:
Duplicate symbol _DeleteCriticalSection
So what can I do? Is there any way to remove the conflict?
Thank you in advance.
I've seen similar things inside FAT libraries where some files were duplicated, leading to duplicate objects. You can try to see if this is the same issue, e.g. if your library is named mystaticlibrary.a
$ nm mystaticlibrary.a | grep DeleteCriticalSection
Now it can be normal to have the symbol multiple times if you have a FAT library (more than one architecture). To see if that's the case do:
$ file mystaticlibrary.a
You should have the symbol for each architecture. If you see more symbols (e.g. 3x DeleteCriticalSection but only 2 arch) then you have a similar issue.
The fix (if it's the same issue) was to split the FAT library (lipo tool), then each architecture specific library, then re-merge everything (arch then FAT).
Your best bet might be to contact your library vendor and ask him for a fixed library (something was likely wrong in the build process). Give them the above command output and they'll likely find out what went wrong.
I currently have ShareKit in my project that is compiled as a static library. It is properly implemented. I also have implemented Amazon's AWS SDK by just adding their framework into my project.
It seems that the duplicate symbol is coming from Amazon's AWS SDK file, "AWSIOSSDK". This is what it looks like:
And that file is colliding with ShareKit's file, libShareKit.a. This is what that file looks like:
Anyway both of these files are ones that I haven't seen before. And it seems that some JSON files are colliding within them.
I have looked at other SO questions and they say to do some things with the compiled sources but none of these files are in the compiled sources from either library.
Here is the exact error Xcode gives:
ld: duplicate symbol _OBJC_CLASS_$_SBJsonParser
Anyway, does anyone have any ideas what I should do? My app does not compile unless I fix this issue.
Thanks!
You could go ahead and split a library archive into its object files and merge them again by leaving out the duplicates.
See the following walkthrough for getting an idea to manage that task:
Avoiding duplicate symbol errors during linking by removing classes from static libraries
Both of these have built SBJsonParser into their static libraries. This is not the correct way to build a static library. Each should build without SBJson and then you should link all of them together with SBJson. There are a couple of solutions:
Rebuild these libraries (or have their maintainers do so) to not include third-party libraries directly into a static library. This is the ideal solution.
Remove the incorrect SBJson files from the .a files using ar. You should be able to do this using ar -t to list the objects in the .a and then ar -d to delete the ones that shouldn't be in there. You could of course also ar -x to extract all the .o files and link them directly.
I had the same issue with FaceBookConnect Framework (let's call it project B) and my project (project A). Both were linking again JSON framework.
The solution is :
Go to Project B > Target > Build Phase > Remove JSON from the "Link Binary with libraries"
Make sure the JSON framework is still in the project (don't remove it) so project B can build
Build your project B you shouldn't get any error. The project should build but not embed the JSON frameworks symbols
Add both project B product (a framework) AND JSON framework in project A
Go to Project A > Target > Build Phase and check that both project B and JSON have been added to the "Link binary with libraries" section
Build your project A
Regards,