Re: Resolving link errors from using two static libs that contain the same symbols
Re: Resolving link errors from using two static libs that contain the same symbols
- Subject: Re: Resolving link errors from using two static libs that contain the same symbols
- From: Roland King <email@hidden>
- Date: Sat, 09 Aug 2014 09:03:36 +0800
> On 9 Aug 2014, at 8:25 am, Jens Alfke <email@hidden> wrote:
>
> A colleague of mine is building an iOS app that includes two open-source static libraries. Unfortunately both of those libraries use the YAJL library and include its code, so when he links the app he gets errors complaining about duplicate symbols like _yajl_status_to_string, etc.
>
> Is there any way around this, short of messing with the projects that build one or the other library and taking out the yajl source files? Basically I'm wondering if there's a linker flag that suppresses duplicate-symbol errors. (Obviously this could have very bad results if the two libraries were using different/incompatible versions of the YAJL library, but in this case they aren't.)
>
I was trying to answer a very similar question yesterday while trying to do something evil with malloc (in an embedded non-Apple project). The answer I ended up with was no you can't. Well not with ld or a compatible linker at least.
My eventual understanding was that the linker, when linking static libraries, applies them in command line order until no symbols are missing. However once a library is read, it's all read, and any duplicates with anything already used are reported and your link fails.
Open source static libraries shouldn't do this, I know why people do do it, but really they shouldn't.
One option which may or may not be easier than fixing the borked library build is to post-process one of the static libraries, ar extract it, remove the bits you don't want and then ar it back up again to make libSomethingNoYAJL.a. Another option is to make the static libraries Xcode projects and then you can do what you like with them, I've had some success with that in the past, you have to keep up with changes as libraries evolve but I've found that not so difficult.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden