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: Saagar Jha <email@hidden>
- Date: Wed, 04 Apr 2018 12:38:22 -0700
Saagar Jha
> On Apr 4, 2018, at 12:17, Redler Eyal <email@hidden> wrote:
>
>>> On Apr 4, 2018, at 9:25 AM, Redler Eyal <email@hidden> wrote:
>>>
>>> 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.
>>
>> Those are the only options I know will work. (But I'm not a linker expert,
>> and it may be that you could get the single-object pre-link to work.)
>>
>> I also work on a 3rd party iOS SDK*; version 1.x was shipped as a static
>> library, but it was such a pain in the butt in many ways. We only did it
>> that way because we started back before iOS apps were allowed to contain
>> dynamic libraries. In 2.0 we happily switched to a framework.
>>
>> I would highly recommend switching to a dynamic library (actually a
>> framework**.) It's the way things are Supposed To Work™, and it's a lot
>> cleaner.
>>
>> —Jens
>>
>> * https://github.com/couchbase/couchbase-lite-ios/
>> ** Apple will reject submissions that include 'bare' dylibs in the app
>> bundle.
>
> We have two issues with the dynamic framework
> 1. It makes it easier to pirate our technology (having our stuff neatly
> packaged seperaterly)
I may be misunderstanding you, but why does your code need to be separate?
Can’t you statically link against your framework, which dynamically opens
OpenCV (packaged as a framework)?
> 2. (More importantly) It makes the client's binary larger since it will have
> to include our full library, including simulator code. (correct me if I'm
> wrong)
No, you should ask your client to remove the simulator slice before submitting
to the App Store.
>
> 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