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

Hi, I've tried to build some binary versions of 5.0.3.

It went fine on a RH8 Linux system I have, if anyone can test that out for
me it's at:
http://bouteloua.erin.utoronto.ca/~smitch

   Index of /~smitch
[ ] grass5.0.3_i686-pc-linux-gnu_bin.tar.gz 14-Nov-2003 09:21 48.6M
[TXT] grass5_i686-pc-linux-gnu_install.sh 14-Nov-2003 09:21 13k

I've tried building on a couple of Suns, both running Solaris 8 and gcc
2.95.3. They also have the Sun compilers, but I'm using gcc. I set
CPPFLAGS to -w to get the configure step past warnings that have to do
with curses and symbols being redefined, a trick from the archives of this
list that I needed for previous builds.

On one of the machines, the GRASS build seems to have gone fine but I just
got an error compiling latest GDAL so that I can add r.in.gdal to the
binary. So I'll look in to that separately. 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 ?

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

Thanks,

Scott

------
Scott W. Mitchell
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building (Office A209)
1125 Colonel By Drive, Ottawa, ON Canada K1S 5B6
+1-613-520-2600 ext 2695 Fax: 1-613-520-4301

On Fri, 14 Nov 2003, Scott W Mitchell wrote:

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 ?

Use 5.3, where the internal proj library has been renamed from libproj to
libgproj, or uninstall your external copy of proj. This is to do with the
search order of libraries under OS X and the way it is sometimes
ignored (shared libraries always used in preference to static with the
same name). Shouldn't be pursued, I would say, as it is already fixed.

/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

Thanks,

Scott

------
Scott W. Mitchell
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building (Office A209)
1125 Colonel By Drive, Ottawa, ON Canada K1S 5B6
+1-613-520-2600 ext 2695 Fax: 1-613-520-4301

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott W Mitchell wrote:

Hi, I've tried to build some binary versions of 5.0.3.

It went fine on a RH8 Linux system I have, if anyone can test that out for
me it's at:
http://bouteloua.erin.utoronto.ca/~smitch

   Index of /~smitch
[ ] grass5.0.3_i686-pc-linux-gnu_bin.tar.gz 14-Nov-2003 09:21 48.6M
[TXT] grass5_i686-pc-linux-gnu_install.sh 14-Nov-2003 09:21 13k

I guess I should point out I have RPMs for Mandrake 9.1 in the usual
place (http://ranger.dnsalias.com/mandrake/9.1/grass/). I will rebuild
on 9.2 once I have a clean build system, and will be uploading to cooker
contrib this weekend.

I haven't run the packages for 9.1 that much though.

Regards,
Buchan

- --
|--------------Another happy Mandrake Club member--------------|
Buchan Milne Mechanical Engineer, Network Manager
Cellphone * Work +27 82 472 2231 * +27 21 8828820x202
Stellenbosch Automotive Engineering http://www.cae.co.za
GPG Key http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/tQoFrJK6UGDSBKcRAryAAJ0enMY9Isy9EF2VbGlZBZFYFjQ1BACfU51E
yDs8+7BR+NLyBEYJdfaZxLo=
=uFJ0
-----END PGP SIGNATURE-----

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@virgin.net>