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: Cody Garvin <email@hidden>
- Date: Thu, 05 Apr 2018 13:03:45 -0700
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
> On Apr 5, 2018, at 12:04 PM, Alex Zavatone <email@hidden> wrote:
>
>
>> 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
_______________________________________________
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