• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Linking additional object files into framework project
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Linking additional object files into framework project


  • Subject: Re: Linking additional object files into framework project
  • From: Jonathan Mitchell <email@hidden>
  • Date: Fri, 11 Apr 2014 17:35:37 +0100

On 11 Apr 2014, at 15:26, Jonathan Prescott <email@hidden> wrote:

> Static libraries don’t get linked when they are created, unlike dynamic libraries.  If your link scheme either links the static library entirely, or as a library (-l B.a) before the framework (-f A.framework), then after the static library is linked in to your program, outstanding externals for the base class methods will be resolved when the framework is linked in.
That sounds promising.

Will the classes defined in the static library be available to clients of the dynamic library?

Jonathan

>
> Jonathan
>
> On Apr 11, 2014, at 5:28 AM, Jonathan Mitchell <email@hidden> wrote:
>
>>
>> On 10 Apr 2014, at 23:08, Jens Alfke <email@hidden> wrote:
>>
>>>
>>> On Apr 10, 2014, at 2:23 PM, Jonathan Mitchell <email@hidden> wrote:
>>>
>>>> A is a standard framework.
>>>> B is a makefile project that contains a large number (~1300) of auto generated source files. The makefile builds the source into objects but doesn’t link them.
>>>
>>> Can you modify the makefile to at least combine the object files into a static library (.a) file? That would make things easier. You can then just add the .a file to your target as though it were any other library. You might be able to add .o files to a target the same way; I’ve never tried it. But I don’t think you need to mess with the linker flags.
>>>
>> Something like that would be my preferred approach but B uses a base class defined in A.
>> I presume that a static library build will fail to link if it cannot resolve all its symbols at link time.
>>
>> It might be better to try and separate out the dependencies into two separate frameworks.
>> The end user would then have to link to two frameworks but that might be okay.
>> Either way the make file will have to link all those objects into something.
>>
>> Thanks
>>
>> J
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list      (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


  • Follow-Ups:
    • Re: Linking additional object files into framework project
      • From: Jonathan Prescott <email@hidden>
References: 
 >Linking additional object files into framework project (From: Jonathan Mitchell <email@hidden>)
 >Re: Linking additional object files into framework project (From: Jens Alfke <email@hidden>)
 >Re: Linking additional object files into framework project (From: Jonathan Mitchell <email@hidden>)
 >Re: Linking additional object files into framework project (From: Jonathan Prescott <email@hidden>)

  • Prev by Date: Re: Removing links from wired properties and IBActions in classes.
  • Next by Date: Re: Linking additional object files into framework project
  • Previous by thread: Re: Linking additional object files into framework project
  • Next by thread: Re: Linking additional object files into framework project
  • Index(es):
    • Date
    • Thread