Re: Avoiding link conflicts with a static library
Re: Avoiding link conflicts with a static library
- Subject: Re: Avoiding link conflicts with a static library
- From: Alex Zavatone <email@hidden>
- Date: Thu, 05 Apr 2018 14:04:44 -0500
> On Apr 5, 2018, at 1:37 PM, Redler Eyal <email@hidden> wrote:
>
>
>> On 5 Apr 2018, at 17:29, Alex Zavatone <email@hidden> wrote:
>>
>>
>>> On Apr 5, 2018, at 4:19 AM, Redler Eyal <email@hidden> 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 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 (email@hidden)
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:
This email sent to email@hidden