[GRASS5] Slight change to post compile message

Hello all

I changed the src/CMD/generic/POST_INSTALL.sh file so that it prints the
absolute path to the newly created bin.$ARCH/gmake5 and
bin.$ARCH/gmakelinks5 giving the proper command line for users to use to
compile Postgres, or ODBC, or the PNG driver. Please check the next time
you run "make" that the paths that are printed are correct. Also. please
let me know if you have any problems.

Thank you.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

From neteler Tue May 29 09:11:52 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id JAA18364; Tue, 29 May 2001 09:11:52 +0100
Date: Tue, 29 May 2001 09:11:51 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: Mike Thomas <miketh@brisbane.paradigmgeo.com>
Cc: grass5 developers list <grass5@geog.uni-hannover.de>
Message-ID: <20010529091151.J13947@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: Mike Thomas <miketh@brisbane.paradigmgeo.com>,
  grass5 developers list <grass5@geog.uni-hannover.de>
References: <000d01c0e352$fbf49ef0$0cb4a8c0@brisbane.paradigmgeo.com> <20010523093007.A8863@hgeo02.geog.uni-hannover.de> <009301c0e742$0ea9f110$0cb4a8c0@brisbane.paradigmgeo.com> <20010528083932.K12157@hgeo02.geog.uni-hannover.de> <00b101c0e7e1$84413e20$0cb4a8c0@brisbane.paradigmgeo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <00b101c0e7e1$84413e20$0cb4a8c0@brisbane.paradigmgeo.com>; from miketh@brisbane.paradigmgeo.com on Tue, May 29, 2001 at 11:48:48AM +1000
Subject: [GRASS5] Re: WinGrass binary.
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 4863
Lines: 146

Hi Mike,

(cc to grass5)

On Tue, May 29, 2001 at 11:48:48AM +1000, Mike Thomas wrote:

Hi again.

SUMMARY: I fixed the NVIZ and PNGDriver link problems, but left the
r.fill.dir one till later. Fixes below. Made a new installation which is
available as noted in my other email today.

Thanks - download is running...

NVIZ is compiled, but won't run unless you put init.tcl in a new directory -
"<GRASS-INSTALL-DIR>/etc/share/tcl8.0".

After fixing this, when run from tcltk, it then gives a usage message in an
XTERM and stops gracefully.

[below more]

DETAILS:
> > (http://www.geog.uni-hannover.de/grass/grass5/source/), rather than the
> > CVS pre-release tag, which has given me some inconsistent build results.
> mhhh, that's surprising as it should be identical.

My guess is that when I did a CVS update in the tagged source I may have
accidentally brought in files from other parts of the CVS.

Is just "cvs update" OK in the tagged source?

Check if you have the Treleasebranch_11_april_2001_5_0_0 applied (check
CVS/Entries). If so, you can run
cvs update -dP

to update it (last night another Xdriver fix from Glynn appeared).

> > To avoid further delays, r.fill.dir, PNGDRIVER and NVIZ are not in the
> > distribution, as I had troubles building each of them.
> Please be so kind and send the error messages, especially of r.fill.dir.

The configure seems to have incorrectly dealt with "values.h". I'll look
into it today.

That's easy to fix:

#################################################################
/cygdrive/e/cvs/grass5.0.0pre1/src/raster/r.fill.dir
  mkdir OBJ.i686-pc-cygwin
  make -f OBJ.i686-pc-cygwin/make.rules

make[1]: Entering directory
`/cygdrive/e/cvs/grass5.0.0pre1/src/raster/r.fill.dir'
gcc -g -O2 -I/cygdrive/e/cvs/grass5.0.0pre1/src/include -c main.c -o
OBJ.i686-pc-cygwin/main.o
In file included from main.c:54:
tinf.h:3: values.h: No such file or directory

Change it to "limits.h":

Index: tinf.h

RCS file: /grassrepository/grass/src/raster/r.fill.dir/Attic/tinf.h,v
retrieving revision 1.1.2.2
diff -r1.1.2.2 tinf.h
3c3
< #include <values.h>
---

#include <limits.h>

values.h is the old, obsolete name for limits.h. I have updated in CVS as
well.

> For PNGDriver I assume problems with libgd, and NVIZ?

PNGDriver's Gmakefile puts ${PNGLIB} before ${GDLIB} which means that the
libgd references to libpng don't get resolved at link time. I swapped them
around and it linked fine. I'll redo the binary package. The fixed line
is:

$(GISBASE)/driver/PNG: $(OFILES) ${DRIVERLIB} ${GISLIB}
${CC} $(LDFLAGS) -o $@ $(OFILES) ${DRIVERLIB} ${GISLIB} $(GRAPH) $(ZLIB)
${GDLIB} ${PNGLIB} $(MATHLIB) $(XDRLIB)

Thanks, fixed as well in CVS.

Why didn't anyone report that problem?

Well, the gcc compiler seem to be able to live with the reversed order.
Both versions compile well here. Anyway, it is reversed now.

Built now and and put in the binary package.

NVIZ -

Two problems -

1. Some libX11 symbols were not being resolved. To
"NVIZ2.2/src/gmakefile.in" I made this change (added $XLIB, probably just
needs reordering of the OGLLIB macro, but this is quicker):

nvwish: $(OBJS) $(VECTLIB) $(BITMAPLIB) $(LINKMLIB)
$(CC) -g -o $@ $(OBJS) $(LDFLAGS) $(SURFLIB) $(IMGLIB) \
$(BITMAPLIB) $(LINKMLIB) $(VECTLIB) \
$(GISLIB) $(MATHLIB) $(XDRLIB) \
$(LIBDIR)/libdatetime.a $(XTRA_LDFLAGS) -ltiff $(XLIB)

2. The install target in "NVIZ2.2/Gmakefile" fails to mv the nvwish.exe, as
it leaves out the .exe extension. This mod at the end of the target does
the job:

install:
..................
if test -f "src/nvwish" ; then mv src/nvwish.exe

                                               ^^^^- without .exe

$(INSTALL_DIR)/$(NVWISH_VER) ; fi
if test -f "src/nvwish.exe" ; then mv src/nvwish.exe
$(INSTALL_DIR)/$(NVWISH_VER) ; fi

Thanks, both fixes are applied to CVS. However, doesn't need $(NVWISH_VER)
the .exe extention as well for winGRASS (second case)? Something like:

if test -f "src/nvwish.exe" ; then mv src/nvwish.exe $(INSTALL_DIR)/$(NVWISH_VER).exe ; fi

> > v.digit /backdrop cell map hangs
> Oops. How does it hang? Does it crash or doesn't it display the map?

The entire bash session hangs without displaying the map. I have to kill
the shell and v.digit.

I tried commenting out the loop in "drawcell()" but it still hangs. My wife
got cranky so I had to stop and look after the children after that! I
haven't had time at work yet to go further on this problem.

Time to get back to making a living for a few hours.

Cheers
Mike Thomas

Perhaps Glynn could recommend on the v.digit problem.

Thanks, Mike, for your fixes,

Markus

I compile GRASS5 on HP-UX with a few errors. The most important one is
with socket. The compiler error is :

#################################################################
/local/grass5.0.0pre1/src/display/devices/lib
  make -f OBJ.hppa1.1-hp-hpux10.20/make.rules

  gcc -g -O2 -I/opt/libpng/include -I/local/grass5.0.0pre1/src/include
             -c connect_sock.c -o OBJ.hppa1.1-hp-hpux10.20/connect_sock.o

connect_sock.c:9: sys/select.h: Fichier ou répertoire inexistant
*** Erreur - code de sortie 1

The <sys/select.h> is missing on HP-UX. What are the symbols that
"connec_socket.c" is looking for in this file so I look where they are.

Thanks.

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

From neteler Tue May 29 18:50:06 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id SAA17578; Tue, 29 May 2001 18:50:05 +0100
Date: Tue, 29 May 2001 18:50:04 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: Grass Developers <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] Socket compilation error on HP-UX
Message-ID: <20010529185004.C5268@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: Grass Developers <grass5@geog.uni-hannover.de>
References: <3B131BB9.ECC814A8@hpcc.nectec.or.th> <3B13E09C.7648C1C0@grr.ulaval.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B13E09C.7648C1C0@grr.ulaval.ca>; from lagace@grr.ulaval.ca on Tue, May 29, 2001 at 01:47:08PM -0400
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 935
Lines: 26

On Tue, May 29, 2001 at 01:47:08PM -0400, Robert Lagacé wrote:

I compile GRASS5 on HP-UX with a few errors. The most important one is
with socket. The compiler error is :

#################################################################
/local/grass5.0.0pre1/src/display/devices/lib
  make -f OBJ.hppa1.1-hp-hpux10.20/make.rules

  gcc -g -O2 -I/opt/libpng/include -I/local/grass5.0.0pre1/src/include
             -c connect_sock.c -o OBJ.hppa1.1-hp-hpux10.20/connect_sock.o

connect_sock.c:9: sys/select.h: Fichier ou répertoire inexistant
*** Erreur - code de sortie 1

The <sys/select.h> is missing on HP-UX. What are the symbols that
"connec_socket.c" is looking for in this file so I look where they are.

Robert,

on my linux box it compiles without sys/select.h. Perhaps you try to
remove that include line and compile again. Maybe this is a residual
from a former version?

Markus

Markus Neteler wrote:

> The <sys/select.h> is missing on HP-UX. What are the symbols that
> "connec_socket.c" is looking for in this file so I look where they are.

on my linux box it compiles without sys/select.h. Perhaps you try to
remove that include line and compile again. Maybe this is a residual
from a former version?

Yep; it's from the original attempt at getting the mouse functions to
terminate on EOF (from a couple of days ago). The select() has now
moved to Serve_Xevent.c. However, it appears that <sys/types.h> is the
correct file to include.

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

Glynn Clements wrote:

> > The <sys/select.h> is missing on HP-UX. What are the symbols that
> > "connec_socket.c" is looking for in this file so I look where they are.
>
> on my linux box it compiles without sys/select.h. Perhaps you try to
> remove that include line and compile again. Maybe this is a residual
> from a former version?

Yep; it's from the original attempt at getting the mouse functions to
terminate on EOF (from a couple of days ago). The select() has now
moved to Serve_Xevent.c.

No it isn't; I was getting confused with command.c (which had a
select() added then removed).

However, it appears that <sys/types.h> is the correct file to
include.

This is still true. I'll change this.

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

Glynn Clements wrote:

Glynn Clements wrote:

> > > The <sys/select.h> is missing on HP-UX. What are the symbols that
> > > "connec_socket.c" is looking for in this file so I look where they are.
> >
> > on my linux box it compiles without sys/select.h. Perhaps you try to
> > remove that include line and compile again. Maybe this is a residual
> > from a former version?
>

I remove the the include line and the compilation did not complained
but I do not know the implact. The XDRIVER is not linked correctly because
/usr/ccs/bin/ld: Can't find library for -lX11.

I need to find the X11 lib.

> Yep; it's from the original attempt at getting the mouse functions to
> terminate on EOF (from a couple of days ago). The select() has now
> moved to Serve_Xevent.c.

No it isn't; I was getting confused with command.c (which had a
select() added then removed).

> However, it appears that <sys/types.h> is the correct file to
> include.

This is still true. I'll change this.

What are the symbols or functions defined there?

--
Glynn Clements <glynn.clements@virgin.net>
_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

Robert Lagacé wrote:

> > > > The <sys/select.h> is missing on HP-UX. What are the symbols that
> > > > "connec_socket.c" is looking for in this file so I look where they are.
> > >
> > > on my linux box it compiles without sys/select.h. Perhaps you try to
> > > remove that include line and compile again. Maybe this is a residual
> > > from a former version?

I remove the the include line and the compilation did not complained
but I do not know the implact.

Removing the line shouldn't cause any problems.

The XDRIVER is not linked correctly because
/usr/ccs/bin/ld: Can't find library for -lX11.

I need to find the X11 lib.

It's normally in "/usr/X11/lib". If it is installed, but the
"configure" script can't find it, you can use the "--x-libraries"
argument to force a specific directory.

> > Yep; it's from the original attempt at getting the mouse functions to
> > terminate on EOF (from a couple of days ago). The select() has now
> > moved to Serve_Xevent.c.
>
> No it isn't; I was getting confused with command.c (which had a
> select() added then removed).
>
> > However, it appears that <sys/types.h> is the correct file to
> > include.
>
> This is still true. I'll change this.

What are the symbols or functions defined there?

The ones for which <sys/select.h> was being used are the fd_set type
and the FD_ZERO and FD_SET macros. In GNU libc 2, these are defined in
<sys/select.h> but that file is included from <sys/types.h>. The
latter is apparently the correct file to include for these
definitions.

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

Glynn Clements wrote:

Robert Lagacé wrote:

> > > > > The <sys/select.h> is missing on HP-UX. What are the symbols that
> > > > > "connec_socket.c" is looking for in this file so I look where they are.
> > > >
> > > > on my linux box it compiles without sys/select.h. Perhaps you try to
> > > > remove that include line and compile again. Maybe this is a residual
> > > > from a former version?
>
> I remove the the include line and the compilation did not complained
> but I do not know the implact.

Removing the line shouldn't cause any problems.

> The XDRIVER is not linked correctly because
> /usr/ccs/bin/ld: Can't find library for -lX11.
>
> I need to find the X11 lib.

The libX11.a and libX11.sl were not installed. The problem is solve
and compilation is OK. Next is testing. Report as soon as it is done.

GRASS wil have one more platform.

It's normally in "/usr/X11/lib". If it is installed, but the
"configure" script can't find it, you can use the "--x-libraries"
argument to force a specific directory.

> > > Yep; it's from the original attempt at getting the mouse functions to
> > > terminate on EOF (from a couple of days ago). The select() has now
> > > moved to Serve_Xevent.c.
> >
> > No it isn't; I was getting confused with command.c (which had a
> > select() added then removed).
> >
> > > However, it appears that <sys/types.h> is the correct file to
> > > include.
> >
> > This is still true. I'll change this.
>
> What are the symbols or functions defined there?

The ones for which <sys/select.h> was being used are the fd_set type
and the FD_ZERO and FD_SET macros. In GNU libc 2, these are defined in
<sys/select.h> but that file is included from <sys/types.h>. The
latter is apparently the correct file to include for these
definitions.

On HP-UX 10.2, fd_set type and FD_ZERO and FD_SET macros are define in
<sys/types.h>. If for other platforms, these definitions are as you
said in <sys/select.h> but included from <sys/types.h>, it not
necessary to put the include statement #include <sys/select.h> since
#include <sys/types.h> is already present. The problem can only exist
for systems where thoses definitions are not included directly or
indirectly by <sys/types.h>. In those case, the include will be
conditional. We need to identify those systems. HP-UX and LINUX
seems OK.

One tempory solution i may be change the following statements in
connect_sock.c

#include <sys/select.h>
#include <sys/time.h>
#include <sys/types.h>

to

#include <sys/time.h>
#include <sys/types.h>

#ifndef _FD_SET

#include <sys/select.h>

#endif

It would be better if everyone check where those are defined on their
platform.

--
Glynn Clements <glynn.clements@virgin.net>
_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

Robert =?iso-8859-1?Q?Lagac=E9?= wrote:

> > > > However, it appears that <sys/types.h> is the correct file to
> > > > include.
> > >
> > > This is still true. I'll change this.
> >
> > What are the symbols or functions defined there?
>
> The ones for which <sys/select.h> was being used are the fd_set type
> and the FD_ZERO and FD_SET macros. In GNU libc 2, these are defined in
> <sys/select.h> but that file is included from <sys/types.h>. The
> latter is apparently the correct file to include for these
> definitions.

On HP-UX 10.2, fd_set type and FD_ZERO and FD_SET macros are define in
<sys/types.h>. If for other platforms, these definitions are as you
said in <sys/select.h> but included from <sys/types.h>, it not
necessary to put the include statement #include <sys/select.h> since
#include <sys/types.h> is already present. The problem can only exist
for systems where thoses definitions are not included directly or
indirectly by <sys/types.h>. In those case, the include will be
conditional. We need to identify those systems. HP-UX and LINUX
seems OK.

One tempory solution i may be change the following statements in
connect_sock.c

[snip]

None of this is necessary; "#include <sys/types.h>" is sufficient.

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

I cimpiled succesfully GRASS on HP-UX except a few modules that I will
talk about later on.

I tested GRASS with the spearfish data set. tcltkgrass started OK, the
monitors
appears correctly and close OK (close ou quit buttoms). I did a few test with
vectors.

The only modules not compiling are

- html with the following message

Copying html pages
Creating man pages
You should be root if gmake5 fails. Otherwise it may be OK.
Converting: blend.sh.html to
/local/grass5.0.0pre1/dist.hppa1.1-hp-hpux10.20/man/man1/blend.sh_.1
Syntaxe : man [ section ] nom ...
ou : man -k mot_clé ...
ou : man -f fichier ...
*** Erreur - code de sortie 1

Arrêt.
GISGEN failure at STEP: html

- d.area with the following message

  gcc -g -O2 -I/opt/libpng/include -I/local/grass5.0.0pre1/src/include
             -c plot.c -o OBJ.hppa1.1-hp-hpux10.20/plot.o
In file included from plot.c:18:
screenpoly.h:39: warning: redefinition of `uint8_t'
/usr/include/sys/_inttypes.h:62: warning: `uint8_t' previously declared here
screenpoly.h:42: conflicting types for `uint32_t'
/usr/include/sys/_inttypes.h:66: previous declaration of `uint32_t'
*** Erreur - code de sortie 1

Arrêt.
GISGEN failure at STEP: src/display/d.area

<<<<<

- g.help with the following message

       gcc -g -O2 -I/opt/libpng/include -I/local/grass5.0.0pre1/src/include
          -c menu.c -o OBJ.hppa1.1-hp-hpux10.20/menu.o
menu.c: In function `F_menu':
menu.c:133: `KEY_REFRESH' undeclared (first use in this function)
menu.c:133: (Each undeclared identifier is reported only once
menu.c:133: for each function it appears in.)
menu.c:138: `KEY_HELP' undeclared (first use in this function)
menu.c:192: `KEY_END' undeclared (first use in this function)
menu.c: In function `F_helpctrl':
menu.c:435: `KEY_REFRESH' undeclared (first use in this function)
menu.c:507: `KEY_END' undeclared (first use in this function)
*** Erreur - code de sortie 1

Arrêt.
GISGEN failure at STEP: src/general/g.help

<<<<<

r.in.png, r.out.png and r.in.gdal because some libraries are not installed yet.

I did not compile Postgress, OBDC nor NVIZ.

THANKS for your support.

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

On Wed, May 30, 2001 at 06:35:06PM -0400, Robert Lagacé wrote:

I cimpiled succesfully GRASS on HP-UX except a few modules that I will
talk about later on.

[snip]

- d.area with the following message

>>>>
  gcc -g -O2 -I/opt/libpng/include -I/local/grass5.0.0pre1/src/include
             -c plot.c -o OBJ.hppa1.1-hp-hpux10.20/plot.o
In file included from plot.c:18:
screenpoly.h:39: warning: redefinition of `uint8_t'
/usr/include/sys/_inttypes.h:62: warning: `uint8_t' previously declared here
screenpoly.h:42: conflicting types for `uint32_t'
/usr/include/sys/_inttypes.h:66: previous declaration of `uint32_t'
*** Erreur - code de sortie 1

Dang, I tried to guard for that. "screenpoly.h" is the last include for
plot.c and has...

#if !defined(uint8_t)
  typedef unsigned char uint8_t;
#endif
#if !defined(uint32_t)
  typedef unsigned long uint32_t;
#endif

But maybe those aren't working? d.area is fairly broken anyway -- Anyone else
want to take a crack at it?

--
Eric G. Miller <egm2@jps.net>

Robert Lagacé wrote:

- g.help with the following message

>>>>
       gcc -g -O2 -I/opt/libpng/include -I/local/grass5.0.0pre1/src/include
          -c menu.c -o OBJ.hppa1.1-hp-hpux10.20/menu.o
menu.c: In function `F_menu':
menu.c:133: `KEY_REFRESH' undeclared (first use in this function)
menu.c:133: (Each undeclared identifier is reported only once
menu.c:133: for each function it appears in.)
menu.c:138: `KEY_HELP' undeclared (first use in this function)
menu.c:192: `KEY_END' undeclared (first use in this function)
menu.c: In function `F_helpctrl':
menu.c:435: `KEY_REFRESH' undeclared (first use in this function)
menu.c:507: `KEY_END' undeclared (first use in this function)

OK; these should be defined in curses.h, but not on HP-UX it seems.
Although I find it odd that it complains about KEY_END but not
KEY_HOME.

I'll fix this.

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

Eric G. Miller wrote:

> - d.area with the following message
>
> >>>>
> gcc -g -O2 -I/opt/libpng/include -I/local/grass5.0.0pre1/src/include
> -c plot.c -o OBJ.hppa1.1-hp-hpux10.20/plot.o
> In file included from plot.c:18:
> screenpoly.h:39: warning: redefinition of `uint8_t'
> /usr/include/sys/_inttypes.h:62: warning: `uint8_t' previously declared here
> screenpoly.h:42: conflicting types for `uint32_t'
> /usr/include/sys/_inttypes.h:66: previous declaration of `uint32_t'
> *** Erreur - code de sortie 1

Dang, I tried to guard for that. "screenpoly.h" is the last include for
plot.c and has...

#if !defined(uint8_t)
  typedef unsigned char uint8_t;
#endif
#if !defined(uint32_t)
  typedef unsigned long uint32_t;
#endif

But maybe those aren't working?

"defined" will only work if those names are #define'd, not if they are
typedef'd.

This should be done with the autoconf AC_CHECK_TYPE macro, although I
would suggest at least using "unsigned int" instead of "unsigned long".
IMHO, "long" being 64 bits is a lot more likely than "int" being
something other than 32.

Ideally config.h should define a type which is known to be of the
correct size, e.g.

  #if sizeof(unsigned int) == 4
  typedef unsigned int grass_uint32_t;
  #elif sizeof(unsigned long) == 4
  typedef unsigned long grass_uint32_t;
  #elif sizeof(unsigned short) == 4
  typedef unsigned short grass_uint32_t;
  #else
  #error Unable to find a 32 bit type
  #endif

Then configure.in can use

  AC_CHECK_TYPE(uint32_t, grass_uint32_t)

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

On Thu, May 31, 2001 at 05:06:45AM +0100, Glynn Clements wrote:

"defined" will only work if those names are #define'd, not if they are
typedef'd.

Durnit, I thought that was the case... Those darn types can exist in too
many files to find the proper include (if they exist). I never got
around to messing with configure for this, 'cause I never got d.area
functioning properly.

This should be done with the autoconf AC_CHECK_TYPE macro, although I
would suggest at least using "unsigned int" instead of "unsigned long".
IMHO, "long" being 64 bits is a lot more likely than "int" being
something other than 32.

Probably a good idea. Really only nead the 8bit unsigned char. But I
think the whole thing is fsck'ed. Am trying to get a version working
with a third party clipping library. Hopefully I can get that working
(it promises to make triangle trips!). If only the API were better
documented, so's I could understand why a certain function call is
causing a segfault ;(. Anyway...

--
Eric G. Miller <egm2@jps.net>

From neteler Thu May 31 08:27:12 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id IAA00881; Thu, 31 May 2001 08:27:12 +0100
Date: Thu, 31 May 2001 08:27:12 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5@geog.uni-hannover.de
Subject: Re: [GRASS5] new Linux Binaries
Message-ID: <20010531082712.C770@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5@geog.uni-hannover.de
References: <E1555sm-00023z-00@paf-linux.ulb.ac.be> <20010530154005.A25677@hgeo02.geog.uni-hannover.de> <3B15B1ED.63F20DBC@hpcc.nectec.or.th>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B15B1ED.63F20DBC@hpcc.nectec.or.th>; from jhickey@hpcc.nectec.or.th on Thu, May 31, 2001 at 09:52:29AM +0700
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 812
Lines: 26

On Thu, May 31, 2001 at 09:52:29AM +0700, Justin Hickey wrote:

Hi Markus

Markus Neteler wrote:
>
> On Wed, May 30, 2001 at 03:19:28PM +0200, mlennert@ulb.ac.be wrote:
> > Markus,
> >
> > Can I recreate the Linux binaries with the May 20 snapshot, or
> > should I use a new snapshot with the latest changes ?
>
> Personally I would prefer the latest code (due to new Xdriver
> improvements). However, this would be 5.0.0pre1b. Or shall I re-tag
> and we produce 5.0.0pre2 ?

If we are going to produce another release then it should be named
5.0.0pre2. I see no reason for using multiple versions of pre1.

O.k. (good luck that pre1 is not anounced yet :slight_smile:

Perhaps we should wait until the V_stuff is fixed? Glynn, Huidae, do
you have a timeline for this?

Regards

Markus

"Eric G. Miller" wrote:

On Wed, May 30, 2001 at 06:35:06PM -0400, Robert Lagacé wrote:
>
> I cimpiled succesfully GRASS on HP-UX except a few modules that I will
> talk about later on.
[snip]
> - d.area with the following message
>
> >>>>
> gcc -g -O2 -I/opt/libpng/include -I/local/grass5.0.0pre1/src/include
> -c plot.c -o OBJ.hppa1.1-hp-hpux10.20/plot.o
> In file included from plot.c:18:
> screenpoly.h:39: warning: redefinition of `uint8_t'
> /usr/include/sys/_inttypes.h:62: warning: `uint8_t' previously declared here
> screenpoly.h:42: conflicting types for `uint32_t'
> /usr/include/sys/_inttypes.h:66: previous declaration of `uint32_t'
> *** Erreur - code de sortie 1

Dang, I tried to guard for that. "screenpoly.h" is the last include for
plot.c and has...

#if !defined(uint8_t)
  typedef unsigned char uint8_t;
#endif
#if !defined(uint32_t)
  typedef unsigned long uint32_t;
#endif

But maybe those aren't working? d.area is fairly broken anyway -- Anyone else
want to take a crack at it?

--
Eric G. Miller <egm2@jps.net>
_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5

I successfully compile d.area with the following change in in screenpoly.h
(wrapping the #if !defined code)

#ifndef __INTTYPES_INCLUDED

#if !defined(uint8_t)
  typedef unsigned char uint8_t;
#endif
#if !defined(uint32_t)
  typedef unsigned long uint32_t;
#endif

#endif

---------------

uint8_t and uint32_t are defined in /usr/include/sys/_inttypes.h where they
are defined under __INTTYPES_INCLUDED the following way

typedef unsigned char uint8_t; /* 8-bit unsigned integer */
typedef unsigned int uint32_t; /* 32-bit unsigned integer */

So as uint32_t should be defined typedef unsigned int uint32_t as suggested.

I do not know by which include file _inttypes.h is pick up.

This solution may work on other systems.

----------------------------

d.area run displaying areas and borders but without area or perimeter
information.
But the module v.area do that.

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

Robert Lagacé wrote:

uint8_t and uint32_t are defined in /usr/include/sys/_inttypes.h where they
are defined under __INTTYPES_INCLUDED the following way

typedef unsigned char uint8_t; /* 8-bit unsigned integer */
typedef unsigned int uint32_t; /* 32-bit unsigned integer */

So as uint32_t should be defined typedef unsigned int uint32_t as suggested.

I do not know by which include file _inttypes.h is pick up.

This solution may work on other systems.

ISO C 9x[1] specifies <stdint.h> for these types. It does state that
"These types need not exist in an implementation", although that's
probably to allow for implementations which don't have any type which
could be used for [u]int64_t.

[1] This is from the 1998-08-03 draft (section 7.18.1.1).

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

On Thu, Jun 14, 2001 at 12:39:15AM +0100, Glynn Clements wrote:

Robert Lagacé wrote:

> uint8_t and uint32_t are defined in /usr/include/sys/_inttypes.h where they
> are defined under __INTTYPES_INCLUDED the following way
>
> typedef unsigned char uint8_t; /* 8-bit unsigned integer */
> typedef unsigned int uint32_t; /* 32-bit unsigned integer */
>
> So as uint32_t should be defined typedef unsigned int uint32_t as suggested.
>
> I do not know by which include file _inttypes.h is pick up.
>
> This solution may work on other systems.

ISO C 9x[1] specifies <stdint.h> for these types. It does state that
"These types need not exist in an implementation", although that's
probably to allow for implementations which don't have any type which
could be used for [u]int64_t.

[1] This is from the 1998-08-03 draft (section 7.18.1.1).

I probably should've never messed with the can of worms. Unfortunately,
these data types can exist in all manner of places on different systems
and with conflicting definitions... I search for some ./configure hacks
to deal with it, but never implemented them since d.area is still
fundamentally broken.

Note: I'm trying to put a replacement together for d.area (actually, I
have one already but the license for some borrowed code is too
restrictive). Also, d.area is only a drawing routine. I don't know
where that bit about reporting area/perimeter info comes from, but it
was never in the code when I started hacking on it.

If you'd like to try a d.area for "non-commercial use only" (the bad
license restriction) I can send or make available a tarball (no uint8_t
type involved!).

--
Eric G. Miller <egm2@jps.net>

Eric G. Miller wrote:

If you'd like to try a d.area for "non-commercial use only" (the bad
license restriction) I can send or make available a tarball (no uint8_t
type involved!).

1. uint8_t is the (very) easy case; "typedef unsigned char uint8_t".

Although I don't think anything actually prohibits "char" from having
more than 8 bits (less than 8 /is/ prohibited), you could safely bet
vital organs that most of GRASS (and a great deal else) wouldn't work
on such a system.

2. uint32_t isn't much harder; if "typedef unsigned int uint32_t" is
wrong on a given platform, plenty of other GRASS programs will also
fail.

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