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: Jim Adams <email@hidden>
- Date: Thu, 05 Apr 2018 20:05:30 +0000
- Thread-topic: 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 <email@hidden> wrote:
>
> 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
>
>> 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
_______________________________________________
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