[GRASSLIST:5588] Re: GRASS 5.0.1 compilation issues

Great! I'll replace that code.

I've been wrestling with compiling all day and have discovered a couple other
issues.

1) For some reason, when compiling the code in directory "r.tiff", the "jpeg"
lib is not included on the compile line. I added "-ljpeg" in Gmakefile and it
appears to compile without errors.

2) When compiling the code in PNGdriver, there is a reference to "sun" and "cos"
which I'm sure are in libm.a. Here I also changed the Gmakefile and added "-lm"
and the code now copiles without errors.

I don't know if these are accidental omissions or platform specific issues.

3) Compiling in src/general/init for "set_data"

ld: warning: symbol `numcodes' has differing sizes:
        (file /usr/local/lib/libncurses.so value=0xa0; file
/usr/lib/libtermlib.so value=0x88);
        /usr/local/lib/libncurses.so definition taken

This looks like a problem with set_data. Which curses library should be used?
I find /usr/lib/libcurses and /usr/local/lib/libncurses. I still get the error
message when starting grass:

  Sorry, I need to know a more specific terminal type than "".

TERM is set to "xterm" ("echo $TERM" just prior to set_data in Init.sh)

4) In one of the email archives, there was a discussion about using fifos.
Should sockets be used in most cases?

Thanks for your help.

Wayne Gibson

From: Glynn Clements <glynn.clements@virgin.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
To: Wayne Gibson <gibson@coas.oregonstate.edu>
Cc: grasslist@baylor.edu
Subject: Re: [GRASSLIST:5585] Re: GRASS 5.0.1 compilation issues

Wayne Gibson wrote:

Running d.where also had some troubles. When I issued the command,
an endless stream of coordinate were displayed until I made the 1st
mouse click. Then the command worked as it should (1 pair of
coordinates per mouse click).

I've found the bug. FWIW, it occurs when an uninitialised variable
happens to contain -1.

You can obtain an updated version of the file from:

http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass/src/display/devices/XDR

IVER/XDRIVER24/Get_w_pnt.c?rev=1.11&content-type=text/plain

The file in question is:

src/display/devices/XDRIVER/XDRIVER24/Get_w_pnt.c

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

-----------------------
Wayne Gibson
Oregon State University
gibson@coas.oregonstate.edu
(541) 737-5696

Wayne Gibson wrote:

I've been wrestling with compiling all day and have discovered a couple other
issues.

1) For some reason, when compiling the code in directory "r.tiff", the "jpeg"
lib is not included on the compile line. I added "-ljpeg" in Gmakefile and it
appears to compile without errors.

Argh:

  LIBTIFF = $(TIFFLIBPATH) $(JPEGLIBPATH) -ltiff $(ZLIB)

The configure script specifically checks for JPEG, and adds
$JPEGLIBPATH $JPEGLIB to the definition of TIFFLIB if it's required.
Of course, that is of absolutely no use if r.tiff/Gmakefile doesn't
actually use $(TIFFLIB).

It should be:

  LIBTIFF = $(TIFF_LIBRARY_DIRS) $(TIFFLIB)

Anything else which is required should have been added to TIFFLIB by
configure (it checks for JPEG, zlib and the math library).

2) When compiling the code in PNGdriver, there is a reference to
"sun" and "cos" which I'm sure are in libm.a. Here I also changed
the Gmakefile and added "-lm" and the code now copiles without
errors.

That's a known bug; the configure script has already been fixed in
CVS.

I don't know if these are accidental omissions or platform specific issues.

Accidents.

However, while something which fails on Linux (which seems to account
for ~90% of our user base) will be found quickly, something that only
fails on a less-popular platform will only be found when someone
actually tests on that platform.

3) Compiling in src/general/init for "set_data"

ld: warning: symbol `numcodes' has differing sizes:
        (file /usr/local/lib/libncurses.so value=0xa0; file
/usr/lib/libtermlib.so value=0x88);
        /usr/local/lib/libncurses.so definition taken

The use of termlib was bogus, and has since been removed.

This looks like a problem with set_data. Which curses library should
be used? I find /usr/lib/libcurses and /usr/local/lib/libncurses.

Normally libraries which are in /usr/lib are a safer bet than those in
/usr/local/lib. However, you don't get to pick and choose specific
directories for specific libraries; if /usr/local/lib is searched for
any library, it is searched for all of them.

Am I correct in assuming that zlib is in /usr/local/lib? If so, then
the only way (AFAIK) to avoid getting the libncurses from
/usr/local/lib is to create a private library directory, populated
with symlinks to the required libraries (e.g. zlib), and specify that
instead of /usr/local/lib.

I still get the error message when starting grass:

  Sorry, I need to know a more specific terminal type than "".

TERM is set to "xterm" ("echo $TERM" just prior to set_data in Init.sh)

OK, then it's a library problem. Possibly termlib, possibly the wrong
libncurses.

Try setting TERMLIB to empty in the src/CMD/head/head.<arch> file,
then re-compiling.

4) In one of the email archives, there was a discussion about using fifos.
Should sockets be used in most cases?

Yes.

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