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

[Glynn Clements]

Markus Neteler wrote:

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

Not all functions have defaults; some of them must be defined by
individual drivers. That includes Graph_Close and Graph_Set.

OTOH, many of the drawing primitives can be defined in terms of other
primitives. E.g. there is a default implementation of Box_abs() which
uses Polygon_abs(), most of the *_rel() functions have implementations
which use the corresponding *_abs() function, etc.

Ultimately, you could implement defaults for everything provided that
the driver provided a function to plot individual pixels. However,
that wouldn't be very efficient. However, the pixel-plotting function
would still be a "reverse" dependency, i.e. the library would have to
depend upon a symbol which couldn't be resolved at the point that the
library was built.

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

Paul seems to have answered that for you.

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

That should be fixed. We shouldn't rely upon it being possible to
build all libraries as shared libraries and, even when it is possible,
it isn't necessarily desirable.

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

AFAIK, the driver library is the only one remaining which has weird
dependencies. With the exception of the DBMI libraries, I fixed the
others (ISTR that coorcnv was one) when I added the option to build
shared libraries in 5.0.x (mk/mid.mk.shlib). IIRC, Radim has since
fixed the DBMI libraries (at least for 5.7).

The problem is that there are essentially cyclic dependencies between
the driver library and the drivers themselves. Each driver depends
upon functions in the driver library, but the driver library also
depends upon functions in the driver.

FWIW, if you want to build DLLs on Windows, this issue will probably
be much more problematic than it was for the Mac.

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

Not really; it's more work than adding another switch to the link
command, but it's mostly boilerplate.

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