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: Fri, 11 Apr 2014 13:23:14 -0400
Depends on what you mean by “definition of classes.” The actual definition of the class is usually in a source file (typically a .h file), while the code for methods is compiled into object code. So, in order to compile class A that needs information about the structure of class B, the class definition for B has to be available to the compiler when compiling the source code of A. The result of the compilation (usually) results in an object file that, aside from the name mangling used in C++ to uniquely identify class method functions, for example, is the same as the object file created from C, Fortran, etc., in a general sense. Header/source data is not contained in the static library, and header files are usually stored in some “include” path that the compiler has access to when compiling code. This is the “classic” way of organizing libraries from Unix, Linux, PrimeOS, VMS, etc.. So, in your case, I would assume that the header files, or other source files, are contained in your Xcode project in some fashion, or references to paths to the header/source files, are part of your build settings.
Frameworks are a slightly different beast. On Mac OS X, frameworks are actually directories that hold the dynamic library, and related headers, resources, etc., needed by the dynamic library. Mac OS X hides the explicit structure to make it easier to manipulate. Xcode knows all about this, and has conventions that include the headers into the compiler input stream when compiling source code that references the framework’s headers. However, once the compile phase is complete, the resulting object code, except for certain nuances such as name-mangling, and incorporation of debug information that references class structure, could have come from any type of source file, and the actual class structure has been encoded into offsets from starting addresses, function jump tables, etc..
So, I quess the best way to answer your question is to understand what you mean by “definition of classes”. Do you have class methods in the A.framework that are calling class methods defined in the B.a static library? If that is the case, you should incorporate the B.a library into the creation of the A.framework since dynamic libraries are linked when they are created, and linking the A.framework will, at the very least, have unresolved external references which will have to be resolved during your program’s link phase. 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. You will probably have to make sure that the header files to both are available as appropriate to the compiler when compiling your program so that the program object file has the appropriate references to the externals defined in both the B.a library, and A.framework framework.
Note that class methods are, at their core, simply subroutines/functions with hidden parameters. The compiler inserts external reference calls into the object code when they are encountered during the compilation, and the linker is responsible for stitching it all together, either at link time with static libraries, or at run-time resolution of dynamic libraries. The class language syntax is primarily for humans to ease the expression of intent for object-oriented programmers to eliminate the bookkeeping that earlier languages like C, Fortran required if you applied object-oriented concepts using those languages.
Jonathan
On Apr 11, 2014, at 12:35 PM, Jonathan Mitchell <email@hidden> wrote:
>
> 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
_______________________________________________
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