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

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

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

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:

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.

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

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

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

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.

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

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

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

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,

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.

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

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

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

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

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

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

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

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

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

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

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

Avoiding link conflicts with a static library

Hi All, 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 application also