Re: Avoiding link conflicts with a static library

2018-04-04 Thread Alex Zavatone 

> 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 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 controlled in the build settings for release builds.  Compiled 
Simulator code is not packaged and should not be packaged in a release build.
___

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

Re: Avoiding link conflicts with a static library

2018-04-04 Thread Alex Zavatone 

> 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 (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)
> 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)
> 
> Eyal

The simulator binary isn’t included in any release build.

The contents of the framework are all compiled, even the graphics and the XIBs.

___

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

Re: Avoiding link conflicts with a static library

2018-04-04 Thread Jens Alfke 


> 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. (correct me if I'm 
> wrong)

The simulator code has to be stripped out before submitting an app. The app 
developer can add a Run Script build phase with a 'lipo' command to do this.

>> 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 apparently not a deal 
breaker for many developers.

—Jens
___

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

Re: Avoiding link conflicts with a static library

2018-04-04 Thread Saagar Jha 

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

Re: Avoiding link conflicts with a static library

2018-04-04 Thread Redler Eyal 
 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 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 (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

Re: Avoiding link conflicts with a static library

2018-04-04 Thread Saagar Jha 

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 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)?

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

> 
> Eyal
> ___
> 
> 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

Re: Avoiding link conflicts with a static library

2018-04-04 Thread Cody Garvin 
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 proper architecture for them to submit. We ran into an 
issue with our sdk including the x86 portion during signing. By stripping that 
out using lipo it reduces the size back to normal sizes. 

Hope this helps. 

Please excuse mobile typos

On Apr 4, 2018, at 12:23 PM, 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 an 
>>> issue with one client whose application also links indirectly (via card-io) 
>>> with openCV. The version of openCV they're using is different then then one 
>>> we use and as a result of this conflict, the application crashes upon use 
>>> of our SDK.
>>> 
>>> 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.
>> 
>> 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 
>> avoids altering the OpenCV sources themselves (you can use a prefix header 
>> to get your #defines into the OpenCV build process if necessary).
>> 
> We thought about this option too but we figured it would require changing all 
> the symbols in the library and not just the ones we use because the functions 
> were using may be calling other functions which could also have the same name 
> in the new and old versions of the library. (Correct me if I'm wrong)
> 
> Eyal
> 
> ___
> 
> 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/cody%40servalsoft.com
> 
> This email sent to c...@servalsoft.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

Re: Avoiding link conflicts with a static library

2018-04-04 Thread Redler Eyal 
>> 
>> 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 links indirectly (via card-io) 
>> with openCV. The version of openCV they're using is different then then one 
>> we use and as a result of this conflict, the application crashes upon use of 
>> our SDK.
>> 
>> 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.
> 
> 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 
> avoids altering the OpenCV sources themselves (you can use a prefix header to 
> get your #defines into the OpenCV build process if necessary).
> 
We thought about this option too but we figured it would require changing all 
the symbols in the library and not just the ones we use because the functions 
were using may be calling other functions which could also have the same name 
in the new and old versions of the library. (Correct me if I'm wrong)

Eyal

___

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

Re: Avoiding link conflicts with a static library

2018-04-04 Thread Redler Eyal 
>> 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 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)
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)

Eyal
___

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

Re: Avoiding link conflicts with a static library

2018-04-04 Thread Jens Alfke 


> 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 
> avoids altering the OpenCV sources themselves (you can use a prefix header to 
> get your #defines into the OpenCV build process if necessary).

Oh — I totally forgot that. We used that technique in our version-1 static 
library.

—Jens
___

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

Re: Avoiding link conflicts with a static library

2018-04-04 Thread Alastair Houghton 
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 an 
> issue with one client whose application also links indirectly (via card-io) 
> with openCV. The version of openCV they're using is different then then one 
> we use and as a result of this conflict, the application crashes upon use of 
> our SDK.
> 
> 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.

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 avoids 
altering the OpenCV sources themselves (you can use a prefix header to get your 
#defines into the OpenCV build process if necessary).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

Re: Avoiding link conflicts with a static library

2018-04-04 Thread Jens Alfke 


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

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

Avoiding link conflicts with a static library

2018-04-04 Thread Redler Eyal 
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 links indirectly (via card-io) with 
openCV. The version of openCV they're using is different then then one we use 
and as a result of this conflict, the application crashes upon use of our SDK.

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.

One direction that seems to make sense is to pre-link openCV with our 
framework. I tried doing that setting the "Perform Single-Object Prelink" to 
YES and added openCV in the "Prelink libraries" setting. That builds OK but 
when we actually try to link with our SDK, the linker seems to complain about 
the openCV symbols as missing.

My Questions:
a. Is there any other solution beside what I've mentioned above?
b. Does the pre link concept make sense as a solution?
c. If b is true, any idea what I could be doing wrong setting up this pre-link?

Any thoughts or ideas on the matter would be much appreciated.

Thanks,


Eyal Redler

"If Uri Geller bends spoons with divine powers, then he's doing it the hard 
way."
--James Randi
www.eyalredler.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