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 Prescott <email@hidden>
- Date: Tue, 15 Apr 2014 15:56:33 -0400
It looks like MySubClass should be part of MyFramework, not MyStaticLib. Not sure how you’ve broken it up the way you have, but, in your example, MySubClass is dependent on MyBaseClass, which implies that MyStaticLib is dependent on MyFramework, not the other way around, which means that linking MyStaticLib into MyFramework may satisfy external references elsewhere in the framework that might be included in MyStaticLib, but not for MySubClass and its methods since there appears nothing in MyFramework that actually references MySubClass, thus, no external references for linker to resolve in MyFramework. If MySubClass is part of the code you want to distribute, it would seem that by including it in the framework, rather than the static library, you will switch the dependency graph around, and then the library works for you.
Back in the day, using Unix systems ld (either directly, or through the cc/c++ wrapper), if you loaded an archive file (.a) as part of the objects without the -l switch, the whole archive library was loaded into the image. I’m assuming you are building MyFramework for distribution, and you want to include the code that would be in MyStaticLib as part of the framework, but, the 1300+ files makes it unwieldy to use the “Xcode way” in a straightforward manner. You might be able to get away with putting “libMyStaticLib.a” in the Other Linker Flags (may need to specify entire path) before any switches. The linker should unconditionally load all the object code in the library into the framework image.
Single File Object Prelink may also be of help
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