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

[Markus Neteler]

On Mon, Nov 17, 2003 at 07:12:18PM +0000, Glynn Clements wrote:
> 
> 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.

Thanks for your explanations!

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

Yes, in fact. It compiles and installs and seems to work.
The aclocal.m4 in CVS is updated.
So GRASS 5.7 also works on Mac OSX with shared libs.

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

OK, someone will address that when it's needed (as usual).

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

Markus