[GRASS5] binaries for 5.0.3 - 1 for testing (Linux), 2 (Sun,Mac) problems

[Glynn Clements]

Scott W Mitchell wrote:

> On the other Sun, however,
> I've got many errors with undefined symbols from curses - e.g.:
> 
> #################################################################
> /dat0/smitch/src/grass-5.0.3/src/imagery/i.points
>   make -f OBJ.sparc-sun-solaris2.8/make.rules
> 
> gcc -L/dat0/smitch/src/grass-5.0.3/src/libes/LIB.sparc-sun-solaris2.8 -s
> -lsocket -o
> /dat0/smitch/src/grass-5.0.3/dist.sparc-sun-solaris2.8/etc/bin/inter/i.points
> OBJ.sparc-sun-solaris2.8/main.o OBJ.sparc-sun-solaris2.8/ask.o
> OBJ.sparc-sun-solaris2.8/ask_mag.o OBJ.sparc-sun-solaris2.8/analyze.o
> OBJ.sparc-sun-solaris2.8/call.o OBJ.sparc-sun-solaris2.8/cell.o
> OBJ.sparc-sun-solaris2.8/cellhd.o OBJ.sparc-sun-solaris2.8/conv.o
> OBJ.sparc-sun-solaris2.8/colors.o OBJ.sparc-sun-solaris2.8/curses.o
> OBJ.sparc-sun-solaris2.8/debug.o OBJ.sparc-sun-solaris2.8/digit.o
> OBJ.sparc-sun-solaris2.8/dot.o OBJ.sparc-sun-solaris2.8/drawcell.o
> OBJ.sparc-sun-solaris2.8/driver.o OBJ.sparc-sun-solaris2.8/equ.o
> OBJ.sparc-sun-solaris2.8/find.o OBJ.sparc-sun-solaris2.8/graphics.o
> OBJ.sparc-sun-solaris2.8/group.o OBJ.sparc-sun-solaris2.8/input.o
> OBJ.sparc-sun-solaris2.8/mark.o OBJ.sparc-sun-solaris2.8/mouse.o
> OBJ.sparc-sun-solaris2.8/points.o OBJ.sparc-sun-solaris2.8/target.o
> OBJ.sparc-sun-solaris2.8/title.o OBJ.sparc-sun-solaris2.8/view.o
> OBJ.sparc-sun-solaris2.8/where.o OBJ.sparc-sun-solaris2.8/zoom.o
> OBJ.sparc-sun-solaris2.8/zoom_box.o OBJ.sparc-sun-solaris2.8/zoom_pnt.o
> -lI -lD -ldisplay -lraster -lgis    -lncurses  -lm  -lnsl    -lz
> Undefined                       first referenced
>  symbol                             in file
> initscr32                           OBJ.sparc-sun-solaris2.8/curses.o
> getcurx                             OBJ.sparc-sun-solaris2.8/curses.o
> getcury                             OBJ.sparc-sun-solaris2.8/curses.o
> w32addch                            OBJ.sparc-sun-solaris2.8/curses.o
> ld: fatal: Symbol referencing errors. No output written to
> /dat0/smitch/src/grass-5.0.3/dist.sparc-sun-solaris2.8/etc/bin/inter/i.points
> collect2: ld returned 1 exit status
> make: ***
> [/dat0/smitch/src/grass-5.0.3/dist.sparc-sun-solaris2.8/etc/bin/inter/i.points]
> Error 1
> 
> I can't find anything on this one in the archives - any suggestions ?

None of those symbols are imported by curses.o file on my Linux box,
and none of them appear in the curses.c source file.

It seems likely that some of the "functions" which are used by
curses.c are actually defined as macros in the curses.h file, and
those macros use the undefined symbols. My guess is:

	initscr	->	initscr32
	getyx	->	getcurx, getcury
	addch	->	w32addch

IOW, it looks like the curses.h header which is included by curses.c
doesn't match the curses library against which curses.o is linked.

Do you have both libcurses and libncurses? If so, try changing the
definition of CURSES in src/CMD/head/head.<arch> to use -lcurses
instead of -lncurses. If not, or if that doesn't work, see if you can
locate a different curses.h file, one which is compatible with
libncurses.

Note: the configure script first checks for initscr in libncurses; it
will only try libcurses if the first check fails. Also, configure
doesn't attempt to verify that a particular header is compatible with
the corresponding library (and I doubt that this is actually feasible
in the general case, although specific known problems could be tested
for).

> Third, the Mac.  I'm not even sure it's worth figuring this out, since
> perhaps with all the work that has gone into getting the newer versions to
> compile cleanly under Darwin/OS X, we should direct people there instead
> for this platform ?  Anyways, I'm interested in opinions on that.
> 
> Meanwhile, IF it should be pursued, I'm getting undefined symbols
> on an OS X system as well, in about a dozen modules.  Here's an example,
> does it ring a bell or tell us anything ?
> 
> /Users/smitch/src/grass-5.0.3/src/general/g.region/cmd
>   make -f OBJ.powerpc-apple-darwin6.8.5/make.rules
> 
> gcc
> -L/Users/smitch/src/grass-5.0.3/src/libes/LIB.powerpc-apple-darwin6.8.5 -s
> -L/sw/lib -o
> /Users/smitch/src/grass-5.0.3/dist.powerpc-apple-darwin6.8.5/etc/bin/cmd/g.region
> OBJ.powerpc-apple-darwin6.8.5/printwindow.o
> OBJ.powerpc-apple-darwin6.8.5/adjust.o
> OBJ.powerpc-apple-darwin6.8.5/main.o OBJ.powerpc-apple-darwin6.8.5/zoom.o
> -lvect -ldig2 -lgis  -lintl -ldatetime -lproj  -lz
> ld: Undefined symbols:
> _pj_do_proj
> _pj_get_kv
> _pj_zero_proj
> make[1]: ***
> [/Users/smitch/src/grass-5.0.3/dist.powerpc-apple-darwin6.8.5/etc/bin/cmd/g.region]
> Error 1
> make: *** [all] Error 1

I know this one; primarily because someone else was recently bitten by
it.

You have a dynamic PROJ library installed (e.g. libproj.dylib) and,
due to a "feature" of the Mac's linker, that is being used instead of
the static library which is built from src/libes/proj.

Changing the name of the library in src/CMD/generic/make.mid from:

	DEPGPROJLIB    = $(LIBDIR)/libproj.a
	GPROJLIB       = -lproj
to:
	DEPGPROJLIB    = $(LIBDIR)/libgproj.a
	GPROJLIB       = -lgproj $(PROJLIB)

should solve the problem (this has already been done in the CVS head). 
Alternatively, you can move or rename the installed PROJ library so
that it doesn't get used.

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