Discussion:
Avoiding link conflicts with a static library
(too old to reply)
Redler Eyal
2018-04-04 16:25:33 UTC
Permalink
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-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net
Jens Alfke
2018-04-04 18:05:25 UTC
Permalink
Post by Redler Eyal
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/ <https://github.com/couchbase/couchbase-lite-ios/>
** Apple will reject submissions that include 'bare' dylibs in the app bundle.
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email s
Redler Eyal
2018-04-04 19:17:19 UTC
Permalink
Post by Jens Alfke
Post by Redler Eyal
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-***@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/gegs%40ml-in.narkive.net

This email sent t
Saagar Jha
2018-04-04 19:38:22 UTC
Permalink
Saagar Jha
Post by Redler Eyal
Post by Jens Alfke
Post by Redler Eyal
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)?
Post by Redler Eyal
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.
Post by Redler Eyal
Eyal
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This e
Redler Eyal
2018-04-04 19:55:42 UTC
Permalink
Post by Saagar Jha
Post by Redler Eyal
Post by Jens Alfke
Post by Redler Eyal
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)
Post by Saagar Jha
Post by Redler Eyal
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-***@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/gegs%40ml-in.narkive.net

This em
Saagar Jha
2018-04-04 20:03:57 UTC
Permalink
Saagar Jha
Post by Redler Eyal
Post by Saagar Jha
Post by Redler Eyal
Post by Jens Alfke
Post by Redler Eyal
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?
Post by Redler Eyal
Post by Saagar Jha
Post by Redler Eyal
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.
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net
Redler Eyal
2018-04-05 08:42:32 UTC
Permalink
Post by Saagar Jha
Post by Redler Eyal
Post by Saagar Jha
Post by Redler Eyal
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?
Perhaps not but I'm wondering
a. Will it actually solve the issue (the conflict with the clients OpenCV)?
b. Is it possible to package a static framework with a dynamic library in one package?


_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sen
Saagar Jha
2018-04-06 00:45:15 UTC
Permalink
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
Post by Redler Eyal
Post by Saagar Jha
Post by Redler Eyal
Post by Saagar Jha
Post by Redler Eyal
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?
Perhaps not but I'm wondering
a. Will it actually solve the issue (the conflict with the clients OpenCV)?
b. Is it possible to package a static framework with a dynamic library in one package?
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to
Alex Zavatone
2018-04-05 00:53:33 UTC
Permalink
Post by Saagar Jha
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)?
Post by Redler Eyal
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-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.nark
Redler Eyal
2018-04-05 09:19:29 UTC
Permalink
Post by Alex Zavatone
Post by Saagar Jha
Post by Redler Eyal
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.
My understanding is that the dynamic lib is copied as a resource and not processed automatically that way.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net
Alex Zavatone
2018-04-05 14:29:07 UTC
Permalink
Post by Redler Eyal
Post by Alex Zavatone
Post by Saagar Jha
Post by Redler Eyal
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.
My understanding is that the dynamic lib is copied as a resource and not processed automatically that way.
But when it is built, it is built as Release or Debug, unless you have added other build configurations. When Archive is selected, that uses Release.

Why would a Simulator i386 architecture be used in a release build? You can check the configuration and see if that architecture is even there in the build config.

- Alex Zavatone

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net
Redler Eyal
2018-04-05 18:37:37 UTC
Permalink
Post by Alex Zavatone
Post by Redler Eyal
Post by Alex Zavatone
Post by Saagar Jha
Post by Redler Eyal
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.
My understanding is that the dynamic lib is copied as a resource and not processed automatically that way.
But when it is built, it is built as Release or Debug, unless you have added other build configurations. When Archive is selected, that uses Release.
Why would a Simulator i386 architecture be used in a release build? You can check the configuration and see if that architecture is even there in the build config.
Because we are building an SDK - for other developers that need to be able to run their app, with our SDK, in the simulator.




_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net
Alex Zavatone
2018-04-05 19:04:44 UTC
Permalink
Post by Redler Eyal
Post by Alex Zavatone
Post by Redler Eyal
Post by Alex Zavatone
Post by Saagar Jha
Post by Redler Eyal
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.
My understanding is that the dynamic lib is copied as a resource and not processed automatically that way.
But when it is built, it is built as Release or Debug, unless you have added other build configurations. When Archive is selected, that uses Release.
Why would a Simulator i386 architecture be used in a release build? You can check the configuration and see if that architecture is even there in the build config.
Because we are building an SDK - for other developers that need to be able to run their app, with our SDK, in the simulator.
I have done this twice. If you need to distribute a version of the framework witth simulator code in it, then you will need another build configuration that does include this. Duplicate a build config and add i386. If you need to strip debug symbols or add debug symbols, then duplicate another build configuration and add or remove those settings.

Create as many build configurations as needed by duplicating and modifying what is needed. Clearly document this for your customer. Build them what they need and send them all the frameworks to link to. Yes, it’s hard.

- Alex Zavatone
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@m
Cody Garvin
2018-04-05 20:03:45 UTC
Permalink
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 our script.

Please excuse mobile typos
Post by Alex Zavatone
Post by Redler Eyal
Post by Alex Zavatone
Post by Redler Eyal
Post by Alex Zavatone
Post by Saagar Jha
Post by Redler Eyal
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.
My understanding is that the dynamic lib is copied as a resource and not processed automatically that way.
But when it is built, it is built as Release or Debug, unless you have added other build configurations. When Archive is selected, that uses Release.
Why would a Simulator i386 architecture be used in a release build? You can check the configuration and see if that architecture is even there in the build config.
Because we are building an SDK - for other developers that need to be able to run their app, with our SDK, in the simulator.
I have done this twice. If you need to distribute a version of the framework witth simulator code in it, then you will need another build configuration that does include this. Duplicate a build config and add i386. If you need to strip debug symbols or add debug symbols, then duplicate another build configuration and add or remove those settings.
Create as many build configurations as needed by duplicating and modifying what is needed. Clearly document this for your customer. Build them what they need and send them all the frameworks to link to. Yes, it’s hard.
- Alex Zavatone
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/cody%40servalsoft.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to geg
Jim Adams
2018-04-05 20:05:30 UTC
Permalink
We build ours using archive before lipo-ing and we don’t have to strip the simulator bits out.
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 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 our script.
Please excuse mobile typos
Post by Alex Zavatone
Post by Redler Eyal
Post by Alex Zavatone
Post by Redler Eyal
Post by Alex Zavatone
Post by Saagar Jha
Post by Redler Eyal
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.
My understanding is that the dynamic lib is copied as a resource and not processed automatically that way.
But when it is built, it is built as Release or Debug, unless you have added other build configurations. When Archive is selected, that uses Release.
Why would a Simulator i386 architecture be used in a release build? You can check the configuration and see if that architecture is even there in the build config.
Because we are building an SDK - for other developers that need to be able to run their app, with our SDK, in the simulator.
I have done this twice. If you need to distribute a version of the framework witth simulator code in it, then you will need another build configuration that does include this. Duplicate a build config and add i386. If you need to strip debug symbols or add debug symbols, then duplicate another build configuration and add or remove those settings.
Create as many build configurations as needed by duplicating and modifying what is needed. Clearly document this for your customer. Build them what they need and send them all the frameworks to link to. Yes, it’s hard.
- Alex Zavatone
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/cody%40servalsoft.com
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/jim.adams%40sas.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkiv
Alex Zavatone
2018-04-05 20:51:49 UTC
Permalink
Post by Jim Adams
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 need to distribute more than one binary.

If a crash is discovered in your framework by the client or by the client’s clients, they are going to want to have simulator and debug symbols support to debug.

Shipping anything out of your company with debug symbols will often be regarded as a security risk, so there is that to consider regarding your intellectual property and agreements with the client. That’s for the managers to decide.

This leaves you with the potential for 3 copies of the binary that you may need to distribute.

I managed this by creating build configs for each and then built or archived according to what was needed.

- Alex Zavatone
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.na
Saagar Jha
2018-04-06 00:49:37 UTC
Permalink
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
Post by Alex Zavatone
Post by Redler Eyal
Post by Alex Zavatone
Post by Saagar Jha
Post by Redler Eyal
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.
My understanding is that the dynamic lib is copied as a resource and not processed automatically that way.
But when it is built, it is built as Release or Debug, unless you have added other build configurations. When Archive is selected, that uses Release.
Why would a Simulator i386 architecture be used in a release build? You can check the configuration and see if that architecture is even there in the build config.
- Alex Zavatone
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@m
Alex Zavatone
2018-04-06 01:06:54 UTC
Permalink
Post by Saagar Jha
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. Release will not have i386 in it unless you add it manually. Like I said, if you set this up in the build configurations, you should be able to get this all to be done automatically.

Unless I’m wrong and someone is willing to share a better way to get this organized within Xcode.

Cheers,
- Alex Zavatone
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.
Saagar Jha
2018-04-06 01:12:31 UTC
Permalink
I’m basing this on rdar://problem/19209161 <rdar://problem/19209161>, which appears to still be open. I haven’t tried this myself.

Saagar Jha
Post by Alex Zavatone
Post by Saagar Jha
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. Release will not have i386 in it unless you add it manually. Like I said, if you set this up in the build configurations, you should be able to get this all to be done automatically.
Unless I’m wrong and someone is willing to share a better way to get this organized within Xcode.
Cheers,
- Alex Zavatone
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This e

Jens Alfke
2018-04-04 21:56:39 UTC
Permalink
Post by Redler Eyal
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.
Post by Redler Eyal
Post by Saagar Jha
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-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml
Redler Eyal
2018-04-05 08:44:37 UTC
Permalink
Post by Jens Alfke
Post by Redler Eyal
Post by Saagar Jha
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.
I guess so and still, it is a bit worse then it was. I was hoping to find a solution that would just work for the existing and future clients.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net
Alex Zavatone
2018-04-05 00:50:39 UTC
Permalink
Post by Redler Eyal
Post by Jens Alfke
Post by Redler Eyal
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-***@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/gegs%40ml-in.narkive.net

Th
Alastair Houghton
2018-04-04 18:34:00 UTC
Permalink
Post by 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.
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-***@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/gegs%40ml-in
Jens Alfke
2018-04-04 18:36:49 UTC
Permalink
Post by Alastair Houghton
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-***@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/gegs%40ml-in.narkive.net

T
Redler Eyal
2018-04-04 19:23:54 UTC
Permalink
Post by Alastair Houghton
Post by 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.
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-***@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/gegs%40ml-in.narkive.net

This ema
Cody Garvin
2018-04-04 19:33:17 UTC
Permalink
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<new_symbol>=<symbol>

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
Post by Redler Eyal
Post by Alastair Houghton
Post by 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.
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
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/cody%40servalsoft.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.ne
Continue reading on narkive:
Loading...