[GRASS5] 5.7: compilation shared libs on Mac OSX failure

[Markus Neteler]

On Mon, Nov 17, 2003 at 02:42:54PM +0000, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > Today I gave another try to the compilation of GRASS 5.7 with shared libs
> > on Mac OSX. All libraries compile, but compilation stops at
> > 'driver' lib needed for XDRIVER:
> > 
> > cd display/drivers/lib
> > make
> > gcc -L/sw/lib -L/grass57exp/dist.powerpc-apple-darwin6.8/lib    -dynamiclib
> > -Wl,-flat_namespace,-U,_cuserid -L/sw/lib
> > -L/grass57exp/dist.powerpc-apple-darwin6.8/lib      \
> >         OBJ.powerpc-apple-darwin6.8/Box_abs.o
> 
> [list of object files snipped]
> 
> > -lgrass_raster -lgrass_display -lgrass_gis -lgrass_datetime  -lintl -o
> > /grass57exp/dist.powerpc-apple-darwin6.8/lib/libgrass_driver.dylib
> > ld: Undefined symbols:
> > _Polygon_abs
> > _can_do_float
> > _reset_color
> > _color
> > _draw_line
> > _Get_location_with_box2
> > _Get_location_with_line2
> > _Get_location_with_pointer2
> > _Graph_Close
> > _Panel_delete
> > _Panel_restore
> > _Panel_save
> > _Graph_Set
> > 
> > The functions are in ../XDRIVER/XDRIVER24/ which is to be compiled later.
> > Should these functions be moved into the driver lib (how?)?
> 
> No. Each driver implements its own version of these functions; you
> can't move all of the different implementations into the same library.

This is not clear to me. Eg Graph_Set in 5.3:
src/display/devices/lib/driverlib.h
/* dummies for the driver functions */
int Graph_Close(void);
int Graph_Set(int, char **);

Practically the functions are not there but just "defined" in driverlib.h.
 
> This appears to be an issue with the nature of MacOSX shared libraries
> (you would have a similar problem trying to build the driver library
> as a Windows DLL).
> 
> With Linux/Solaris, shared libraries can contain unresolved symbols,
> so long as those symbols are resolved whenever the library is actually
> used to build an executable. It appears that MacOSX libraries don't
> allow unresolved symbols; at least, not with the switches which are
> being used here.

Possibly. Any MacOSX expert here who could recommend the magic flag?
 
> It may be that there is a linker switch to allow unresolved symbols in
> shared libraries. If not, the simplest solution is to build the driver
> library as a static library (I don't know how to do this with the 5.7
> build system).

Globally it's the
--enable-shared

Locally it's not implemented.
 
> Actually, you may have to use a static library in any case. The driver
> library defines default implementations for various functions; with a
> shared library, the default implementations may be used instead of
> those provided by the driver.

OK, but the XDRIVER seems to be the only significant code piece where 
shared libs with current flags don't compile. All other stuff is fixed and
compiling, that's why I did't give up already.
 
> The only other solution would be to re-design the interface between
> the driver library and the drivers, so that each driver has to
> register the driver-specific functions with the driver library at
> run-time (i.e. callbacks). The driver library would then call those
> functions via pointers.

Sounds like quite some work. 

Markus