[GRASS5] 5.1 build problems on Solaris 8 Sparc
glynn.clements at virgin.net
Mon Mar 3 18:28:58 EST 2003
cheg01 at attbi.com wrote:
> Before I found this, there were several other build issues. I have fixed up
> many of them by direct editing of makefiles because I don't know anything
> about how configure and make really work. I hope someone can translate them
> into real fixes
> Other fixups:
> Had to add "-lresolv" to XEXTRALIBS in Platform.make to support
> "inet_aton" in several .c files.
1. That *shouldn't* work. XEXTRALIBS is only meant to be used by
programs which use X11 (i.e. XDRIVER, NVIZ, maybe a couple of other
2. This problem is equally applicable to 5.0. If any module uses
inet_aton(), the configure script should check for it, and the
module's Makefile should have an appropriate library dependency.
> The variable PQLIB is set equal to "-lpq" in
> /include/Make/Platform.make. This does not work wit the way the variable is
> used in the Makefiles.
This was reported a long time ago; I'm surprised that it hasn't been
> I edited "/include/Make/Grass.make" to replace
> $(PQLIB) with the absolute path to the library
> ("/usr/local/pgsql/lib/libpq.a" in my case) in the "VECTLIB=" definition.
> That fixed the "-lpq not found" error in many makefiles.
The correct fix is not to use $(PQLIB) as a dependency in the
Makefiles. If you can provide a list of modules which generate errors,
I'll fix them.
> Solaris did not accept the syntax "@test -e". I replaced it with
> "@test -r" in:
I would think that "test -x" would be preferable; does Solaris support
More generally, there should be a predefined function for generating a
link, rather than repeating the code for each executable. Actually,
the entire body of the rule should probably be a predefined function.
> To get -lsocket and -lresolve in the necessary places, I had to add
> $(XEXTRALIBS) to LIBES in the Makefile for:
OK; I didn't expect it to work. Right approach, wrong variable.
XEXTRALIBS is meant to be specific to X11.
The right solution is to create additional variables, e.g. SOCKETLIB
and RESOLVLIB, and use those in the appropriate Makefiles. However, a
module's Makefile should only mention those libraries if the module
itself requires those functions.
In most of the cases you list, it's more likely that one of the
libraries which the module uses requires the library. In which case,
the variable for the library should include the necessary
dependencies, so the module would get the dependencies automatically.
E.g. the raster library uses socket functions, so the definition of
RASTERLIB should include the socket library (at present, full
pathnames are being used, which is wrong).
Glynn Clements <glynn.clements at virgin.net>
More information about the grass-dev