Re: Linking additional object files into framework project
Re: Linking additional object files into framework project
- Subject: Re: Linking additional object files into framework project
- From: Jonathan Mitchell <email@hidden>
- Date: Wed, 16 Apr 2014 13:20:25 +0100
On 15 Apr 2014, at 20:56, Jonathan Prescott <email@hidden> wrote:
> The linker should unconditionally load all the object code in the library into the framework image.
This is the goal.
> Single File Object Prelink may also be of help
I put together a test project to investigate this:
http://github.com/mugginsoft/Single-Object-Prelink-Framework-Demo
And after seem experimentation it works.
symbols MyFramework
MyFramework [x86_64, 0.000367 seconds]:
A5611C5D-B68C-3E50-87C9-4A866F1C5FD0 MyFramework [DYLIB, ObjC-RR, FaultedFromDisk]
0x0000000000000000 ( 0xfd9) MACH_HEADER
0x0000000000000fd9 ( 0x27) __TEXT __objc_classname
0x0000000000001000 ( 0x18) __DATA __objc_classlist
0x0000000000001018 ( 0x8) __DATA __objc_imageinfo
0x0000000000001020 ( 0x1b0) __DATA __objc_const
0x00000000000011d0 ( 0xf0) __DATA __objc_data
0x00000000000011d0 ( 0x28) OBJC_METACLASS_$_MyBaseClass [EXT, NameNList, MangledNameNList, NList] // defined in framework
0x00000000000011f8 ( 0x28) OBJC_CLASS_$_MyBaseClass [EXT, NameNList, MangledNameNList, NList]
0x0000000000001220 ( 0x28) OBJC_METACLASS_$_myUncalledClass [EXT, NameNList, MangledNameNList, NList] // defined in static lib
0x0000000000001248 ( 0x28) OBJC_CLASS_$_myUncalledClass [EXT, NameNList, MangledNameNList, NList]
0x0000000000001270 ( 0x28) OBJC_METACLASS_$_MySubClass [EXT, NameNList, MangledNameNList, NList] // defined in static lib
0x0000000000001298 ( 0x28) OBJC_CLASS_$_MySubClass [EXT, NameNList, MangledNameNList, NList]
The crucial steps are:
1. set build phase Perform Single-Object Prelink to YES
2. set Prelink libraries to path os static lib to be pre linked
3. link the static library to the framework as normal.
Two linker phases are now generated.
The first calls ld -r to produce a master.o object derived from the static lib.
The second calls the clang driver and automatically links the master.o object into the framework along with the other framework objects.
I could find no official Xcode documentation on the three pre link build settings.
This is quite a neat trick and it’s a pity that it is not more widely known.
Thanks for plugging away at this.
Jonathan
>
> Jonathan
>
> On Apr 15, 2014, at 4:24 AM, Jonathan Mitchell <email@hidden> wrote:
>
>>
>> On 14 Apr 2014, at 01:29, Jonathan Prescott <email@hidden> wrote:
>>
>>> Why can’t you simply link in MyStaticLib in addition to MyFramework? Link them both into MyApp. That way, additional symbols that MyApp needs that MyFramework doesn’t, can get resolved by the linker for MyApp.
>>>
>>> Jonathan
>> If this were a single project then yes.
>> However, the object files in question are part of a FOSS project and I really want to distribute the code as a framework in order to gain all the advantages that accrue.
>>
>> Jonathan
>>>
>>> On Apr 11, 2014, at 4:34 PM, Jonathan Mitchell <email@hidden> wrote:
>>>
>>>>
>>>> On 11 Apr 2014, at 18:23, Jonathan Prescott <email@hidden> wrote:
>>>>
>>>>> You may still need to link both libraries as indicated previously if the program directly invokes class methods defined in the B.a library without going through the A.framework.
>>>>
>>>> I put together a trivial sample project that mimics the proposed solution:
>>>>
>>>> 1. MyStaticLib defines MySubClass : MyBaseClass
>>>>
>>>> 2. MyFramework defines MyBaseClass : NSObject
>>>>
>>>> 3. MyFramework links in MyStaticLib
>>>>
>>>> 4. MyApp links to MyFramework.
>>>>
>>>>
>>>> MyApp can only utilise symbols defined in MyStaticLib if MyFramework itself references the same symbols, which makes sense.
>>>> symbols(1) confirms this.
>>>>
>>>> So this approach won’t work unless the linker can be persuaded to link all unreferenced objects in MyStaticLib into MyFramework (I tried -ObjC, -all_load and -Xlinker -reexport_library without success).
>>>> I thought that I might be onto something with -reexport_library or -sub_library but these seem to require a dylib argument.
>>>>
>>>> Note that I am only going down this separate makefile target route because the 1300+ number of object files involved is too slow and unwieldy for a regular Xcode project.
>>>>
>>>> So perhaps passing an additional/augmented -filelist argument into my framework build will be the way forward.
>>>>
>>>> Jonathan
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
_______________________________________________
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