Re: Avoiding link conflicts with a static library

I’m basing this on rdar://problem/19209161 , which appears to still be open. I haven’t tried this myself. Saagar Jha > On Apr 5, 2018, at 18:06, Alex Zavatone wrote: > > >> On Apr 5, 2018, at 7:49 PM, Saagar Jha > > wrote: >> >> I think there used to be a bug (mi

Re: Avoiding link conflicts with a static library

> On Apr 5, 2018, at 7:49 PM, Saagar Jha wrote: > > I think there used to be a bug (might still be?) where Xcode didn’t > automatically strip out the x86 simulator slices when you were archiving. > > Saagar Jha When looking at the Archive scheme, it should use Release as the build config. R

Re: Avoiding link conflicts with a static library

I think there used to be a bug (might still be?) where Xcode didn’t automatically strip out the x86 simulator slices when you were archiving. Saagar Jha > On Apr 5, 2018, at 07:29, Alex Zavatone wrote: > > >> On Apr 5, 2018, at 4:19 AM, Redler Eyal wrote: >> > 2. (More importantly

Re: Avoiding link conflicts with a static library

You could weak link against OpenCV then dlopen it at runtime depending on whether it’s already loaded or not. As for packaging, I’d stick them both in a zip with a README telling them where to drag each thing in Xcode. Saagar Jha > On Apr 5, 2018, at 01:42, Redler Eyal wrote: > > We have

Re: Avoiding link conflicts with a static library

> On Apr 5, 2018, at 3:05 PM, Jim Adams wrote: > > We build ours using archive before lipo-ing and we don’t have to strip the > simulator bits out. My point was that when you distribute to clients, they will want to test using a simulator, but will want to ship without it. So, you’ll likely

Re: Avoiding link conflicts with a static library

We build ours using archive before lipo-ing and we don’t have to strip the simulator bits out. > On Apr 5, 2018, at 4:03 PM, Cody Garvin wrote: > > EXTERNAL > > We send them one that is lipod then give them a build phase script that > strips the opposite architecture out. A bit easier than sw

Re: Avoiding link conflicts with a static library

We send them one that is lipod then give them a build phase script that strips the opposite architecture out. A bit easier than switching frameworks that could potentially have different versions and avoid separate targets to add the different architecture library to. Let me know if you’d like o

Re: Avoiding link conflicts with a static library

> On Apr 5, 2018, at 1:37 PM, Redler Eyal wrote: > > >> On 5 Apr 2018, at 17:29, Alex Zavatone wrote: >> >> >>> On Apr 5, 2018, at 4:19 AM, Redler Eyal wrote: >>> > >> 2. (More importantly) It makes the client's binary larger since it will >> have to include our full library,

Re: Avoiding link conflicts with a static library

> On 5 Apr 2018, at 17:29, Alex Zavatone wrote: > > >> On Apr 5, 2018, at 4:19 AM, Redler Eyal wrote: >> > 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)

Re: Avoiding link conflicts with a static library

> On Apr 5, 2018, at 4:19 AM, Redler Eyal wrote: > >>> 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 s

Re: Avoiding link conflicts with a static library

>> >>> 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. > > This is co

Re: Avoiding link conflicts with a static library

> >>> 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. > > Any app using Carthage already has to do this, so it's appare

Re: Avoiding link conflicts with a static library

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, whic

Re: Avoiding link conflicts with a static library

> On Apr 4, 2018, at 2:38 PM, Saagar Jha wrote: > > > Saagar Jha > > 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

Re: Avoiding link conflicts with a static library

> On Apr 4, 2018, at 2:17 PM, Redler Eyal wrote: > >>> On Apr 4, 2018, at 9:25 AM, Redler Eyal 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 (w

Re: Avoiding link conflicts with a static library

> On Apr 4, 2018, at 12:17 PM, Redler Eyal wrote: > > 1. It makes it easier to pirate our technology (having our stuff neatly > packaged seperaterly) > 2. (More importantly) It makes the client's binary larger since it will have > to include our full library, including simulator code. (corre

Re: Avoiding link conflicts with a static library

Saagar Jha > On Apr 4, 2018, at 12:55, Redler Eyal wrote: > > On Apr 4, 2018, at 9:25 AM, Redler Eyal 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

Re: Avoiding link conflicts with a static library

On Apr 4, 2018, at 9:25 AM, Redler Eyal 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 openC

Re: Avoiding link conflicts with a static library

Saagar Jha > On Apr 4, 2018, at 12:17, Redler Eyal wrote: > >>> On Apr 4, 2018, at 9:25 AM, Redler Eyal 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

Re: Avoiding link conflicts with a static library

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= The x86 and arm binaries will need to be stripped during archive time for your client, leaving only the pro

Re: Avoiding link conflicts with a static library

>> >> 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 appl

Re: Avoiding link conflicts with a static library

>> On Apr 4, 2018, at 9:25 AM, Redler Eyal 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) >>

Re: Avoiding link conflicts with a static library

> On Apr 4, 2018, at 11:34 AM, Alastair Houghton > wrote: > > 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

Re: Avoiding link conflicts with a static library

On 4 Apr 2018, at 17:25, Redler Eyal 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

Re: Avoiding link conflicts with a static library

> On Apr 4, 2018, at 9:25 AM, Redler Eyal 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