[GRASSLIST:5612] Re: GRASS 5.0.1 compilation issues

[Wayne Gibson]

I've managed to successfully compile GRASS on our SUN.  There were a couple 
changes necessary.

In addition to the changes Glynn suggested below, the main change was indeed due 
to the curses library.

curses library
--------------
At least on our system, I switched to libcurses(/usr/lib/libcurses.a or 
/usr/ccs/libcurses.a) and not libncurses.  This fixed the issues with the 
compile of "set_data".  Don't exactly know the ramifications of that decision 
but I got a clean compile and so far GRASS seems to work.  To do this, I 
modified the file src/CMD/head/head directly before compiling.  Is there some 
way that the configure script could be modified to use a different library for 
SUN's (assuming this was the correct fix)?

Environmental Variables
-----------------------
One additional behavior I've noticed is that the GRASS_WIDTH, GRASS_HEIGHT, and 
other xwindow variables are not being picked up in the GRASS environment.  If I 
start d.mon, the values are not recognized.  I went into the grass5 script that 
is installed in ${prefix}/bin and added the following:

if [ -f $GISRC ] ; then
    GRASS_WIDTH=`awk '/WIDTH/ {print $2}' $GISRC`
    GRASS_HEIGHT=`awk '/HEIGHT/ {print $2}' $GISRC`
    XDRIVER_LEFT=`awk '/LEFT/ {print $2}' $GISRC`
    XDRIVER_TOP=`awk '/TOP/ {print $2}' $GISRC`
    XDRIVER_TRUECOLOR=`awk '/TRUECOLOR/ {print $2}' $GISRC`
fi

export GRASS_WIDTH GRASS_HEIGHT XDRIVER_LEFT XDRIVER_TOP XDRIVER_TRUECOLOR

The values are now picked up by d.mon.

Thanks for the help,

Wayne Gibson

>From: Glynn Clements <glynn.clements at virgin.net>
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>To: Wayne Gibson <gibson at coas.oregonstate.edu>
>Cc: grasslist at baylor.edu
>Subject: [GRASSLIST:5589] Re: GRASS 5.0.1 compilation issues
>X-IMID: elron.baylor.edu
>X-OriginalArrivalTime: 18 Feb 2003 00:50:29.0416 (UTC) 
FILETIME=[BBAB7280:01C2D6E7]
>X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
>
>
>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 at virgin.net>
>

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