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: Redler Eyal <email@hidden>
- Date: Wed, 04 Apr 2018 22:55:42 +0300
>>>> 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)?
At the moment, we deliver a static framework. This is linked statically to the
client's app and delivered inside the main executable to the app store. If we
switch to a dynamic library then our library will be a separate component that
is delivered as such to the app store. The potential pirate will only have to
dig our the library from the application package (and overcome the other
protections, of-course)
>
>> 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.
I guess, but it would hurt the usage simplicity. Certainly compared to the
current solution as a static library.
_______________________________________________
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