Saagar Jha > On Apr 4, 2018, at 12:55, Redler Eyal <e...@mellel.com> wrote: > >>>>> On Apr 4, 2018, at 9:25 AM, Redler Eyal <e...@mellel.com> 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 (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com > > This email sent to saa...@saagarjha.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
