[GRASS5] Re: 2 bug fixes for recent experimental release

On Mon, Apr 29, 2002 at 12:44:44PM -0400, Jaro Hofierka wrote:

Markus,

recently I did a cvs update of my experimental grass code and I realized
that some scripts did not work (e.g. g3.createwind). I removed all grass
files and re-installed it using a snapshot. The same result.
I have found out that the problem is in ~/src/general/init/init.sh where
the followong line is missing: export LOCATION
(when you cd to $LOCATION, it does not work).

Jaro,
(cc grass5)

LOCATION is deprecated to allow for parallel sessions.
See
http://grass.itc.it/pipermail/grass5/2002-March/002417.html

All scripts have been updated accordingly. I also updated
the g3.createwind and friends recently, perhaps that's
not yet in the CVS snapshot.

You can easily update
cd grasssrc
cvs login
PW: grass
cvs up -dP

Then recompile. There is no need to delete code locally,
just upgrade as above.

The trick to update scripts is: Add on top:
eval `g.gisenv`
: ${GISBASE?} ${GISDBASE?} ${LOCATION_NAME?} ${MAPSET?}
LOCATION=$GISDBASE/$LOCATION_NAME/$MAPSET

The $LOCATION must be constructed inside the script now.

Note: For PERL scripts I do not have a cool codepiece yet.
Only a workaround to simulate the "eval" function from shell scripts
in PERL scripts (help desired).

Also, in r3.showdspf.openGL the following library has to be added to
Gmakefile in order to get compilation without errors: -lGLw

I assume that the problem is elsewhere since no longer hardcoded
library names should be used (portability). This is defined
by "configure".

I'll check that since I also have troubles to compile it.

The corrected files are in the fix.tar.gz file bellow. Please update
your cvs files. Thanks.

More soon,

Markus

Markus Neteler wrote:

> Also, in r3.showdspf.openGL the following library has to be added to
> Gmakefile in order to get compilation without errors: -lGLw

I assume that the problem is elsewhere since no longer hardcoded
library names should be used (portability). This is defined
by "configure".

A while back, the setting of LGLWM (libGLw[M]) was removed from
configure, because it wasn't being used by any of the enabled modules.

A configure test is problematic because there are so many permutations
of this library[1], and it exports so few symbols:

$ nm /usr/X11R6/lib/libGLwM.a | fgrep ' T '
00000750 T GLwCreateM1DrawingArea
00000750 T GLwCreateM2DrawingArea
00000000 T GLwDrawingAreaMakeCurrent
00000020 T GLwDrawingAreaSwapBuffers

$ nm /usr/local/lib/libGLw.a | fgrep ' T '
00000a5c T GLwDrawingAreaMakeCurrent
00000a80 T GLwDrawingAreaSwapBuffers
00000b94 T GLwCreateMDrawingArea

$ nm /usr/src/Mesa-3.4.1/lib/libGLw.a | fgrep ' T '
00000888 T GLwDrawingAreaMakeCurrent
000008b4 T GLwDrawingAreaSwapBuffers

Older versions only define GLwCreateMDrawingArea, while newer versions
have the two GLwCreateM?DrawingArea symbols, and GLwCreateMDrawingArea
is a macro which expands to one of those two symbols depending upon
the Motif version. But the autoconf AC_CHECK_LIB() test doesn't work
with macros.

The other two symbols are also exported by a non-Motif version of the
library, which won't work with r3.showdspf.openGL.

[1] Ihe SGI version, from either Mesa-x.x/widgets-sgi or XFree86 4.0,
is called libGLw.a, and includes both Motif and non-Motif widgets. The
Mesa version, from Mesa-x.x/widgets-mesa, is split into lib[Mesa]GLw.a
(non-Motif) and lib[Mesa]GLwM.a (Motif), and they may be called either
libGLw* or libMesaGLw*.

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