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

[Glynn Clements]

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 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.

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).

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.

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.

-- 
Glynn Clements <glynn.clements at virgin.net>