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 13:03:57 -0700
Saagar Jha
> On Apr 4, 2018, at 12:55, 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)?
>
> 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)
OK, but is there anything stopping you from having your static library
dynamically open OpenCV?
>
>>
>>> 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
_______________________________________________
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