Re: Avoiding link conflicts with a static library
Re: Avoiding link conflicts with a static library
- Subject: Re: Avoiding link conflicts with a static library
- From: Cody Garvin <email@hidden>
- Date: Wed, 04 Apr 2018 12:33:17 -0700
With the symbols, I believe you only need to convert the public symbols. Not
sure how much of an undertaking it is with that library. You can also do this
with other c flags using the -D<new_symbol>=<symbol>
The x86 and arm binaries will need to be stripped during archive time for your
client, leaving only the proper architecture for them to submit. We ran into an
issue with our sdk including the x86 portion during signing. By stripping that
out using lipo it reduces the size back to normal sizes.
Hope this helps.
Please excuse mobile typos
On Apr 4, 2018, at 12:23 PM, Redler Eyal <email@hidden> wrote:
>>>
>>> We're developing an SDK for iOS, the SDK is delivered in a
>>> statically-linked framework. Our library uses openCV and we link OpenCV
>>> into the delivered framework binary.
>>>
>>> This SDK was deployed successfully with some clients but we're having an
>>> issue with one client whose application also links indirectly (via card-io)
>>> with openCV. The version of openCV they're using is different then then one
>>> we use and as a result of this conflict, the application crashes upon use
>>> of our SDK.
>>>
>>> We are aware that the following are possible solutions to the problem:
>>> a. Switch to use the same version of OpenCV as our client.
>>> b. Build our framework as a dynamic library (where we a supposed to be able
>>> to hide openCV inside)
>>> Both of these options are not optimal for us and we trying to see if we
>>> have any other option.
>>
>> You could rename the symbols in your copy of OpenCV so that they don’t match
>> the standard ones. One way to do that is with the preprocessor (use #defines
>> to change the names of the OpenCV functions you use), which potentially
>> avoids altering the OpenCV sources themselves (you can use a prefix header
>> to get your #defines into the OpenCV build process if necessary).
>>
> We thought about this option too but we figured it would require changing all
> the symbols in the library and not just the ones we use because the functions
> were using may be calling other functions which could also have the same name
> in the new and old versions of the library. (Correct me if I'm wrong)
>
> Eyal
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden