Question

I thought one feature of dynamic libraries (and by extension Apple’s Mach-O Frameworks) was to leave some symbols (methods) undefined until the using application gets linked, but it appears all symbols have to be resolved for clang++ to successfully build a Framework.

For example, in building a framework for flight simulations, one might leave a C routine named aero undefined (but with an ‘extern aero()’ specification.) But XCode 4.2 refuses to build the framework, calling _aero an “undefined symbol.”

Here’s the header file included by both Objective-C and ANSI-C routines:

// FlightVehicleCAdapter_data.h

#ifndef FlightVehicleCAdapter_data_h
#define FlightVehicleCAdapter_data_h

#ifdef __cplusplus
external "C" {
#endif

extern void aero( void );

#ifdef __cplusplus
}
#endif

And here is where it gets called:

// FlightVehicleCAdapter.m

-(void) calcAero {
    aero();
    [self setBodyAeroForce_lb:   [lsVector3 vectorFromScalarX:fv_data->f_aero_v.x
                                                            Y:fv_data->f_aero_v.y
                                                            Z:fv_data->f_aero_v.z]];
    [self setBodyAeroMoment_ftlb:[lsVector3 vectorFromScalarX:fv_data->m_aero_v.x
                                                            Y:fv_data->m_aero_v.y
                                                            Z:fv_data->m_aero_v.z]];

}

I had hoped to be able to define the real aero() routine in the application that would link this framework, but when trying to build the framework itself the linker refuses to build it without a concrete aero() implementation:

Undefined symbols for architecture [i386|x86_64]:
  "_aero", referenced from:
    -[FlightVehicleCAdapter calcAero] in FlightVehicleCAdapter.o

So I then defined a dummy aero() routine:

// dummy_aero.c
// not showing fv_data structure definition for clarity

void aero(void){
    fv_data->f_aero_v.x = 0.0; 
    fv_data->f_aero_v.y = 0.0;
    fv_data->f_aero_v.z = 0.0;

    fv_data->m_aero_v.x = 0.0;
    fv_data->m_aero_v.y = 0.0;
    fv_data->m_aero_v.z = 0.0;
}

This definition of aero() satisfies clang++ such that the Mach-O framework (dynamic library) is successfully built. But when I link the resulting framework with the application target which includes a non-trivial aero() routine, the framework’s dummy aero() is being called instead of the application’s aero().

Answer 1

You need to pass the -bundle_loader <executable> option to the linker, although I’m not sure that works for frameworks. Alternatively, you can use -undefined dynamic_lookup.