[GRASS5] Re: bug in configure routine

GRASS GRASS developer
1

From: Jan-Oliver Wagner <jan@intevation.de>
Subject: Re: [GRASS5] Re: bug in configure routine

> Hmm, yes you're right. You can use --with-bindir instead of --bindir.

Yes, I have done that to compile GRASS :slight_smile:

> $bindir, created by --bindir, is not used though defined.
> $BINDIR, created by --with-bindir, is used instead.
>
> So i suggest to remove --bindir and other unused options of configure.
> Any objection?

The configure environment should just behave in a general way
(as it is widely used) and be consistent.

Jan

OK, however, those options do not work right now.
If we want to be consistent, those options should be fixed to work correctly.
In this case, what should be used if --bindir and --with-bindir both given?

Also, not a big deal. :slight_smile:

Huidae Cho

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

On Wed, Nov 22, 2000 at 01:37:01AM +0900, GRASS wrote:

From: Jan-Oliver Wagner <jan@intevation.de>
Subject: Re: [GRASS5] Re: bug in configure routine
> > Hmm, yes you're right. You can use --with-bindir instead of --bindir.
>
> Yes, I have done that to compile GRASS :slight_smile:
>
> > $bindir, created by --bindir, is not used though defined.
> > $BINDIR, created by --with-bindir, is used instead.
> >
> > So i suggest to remove --bindir and other unused options of configure.
> > Any objection?
>
> The configure environment should just behave in a general way
> (as it is widely used) and be consistent.
>
> Jan
>

OK, however, those options do not work right now.
If we want to be consistent, those options should be fixed to work correctly.
In this case, what should be used if --bindir and --with-bindir both given?

Remove --with-bindir
and make --bindir work.

If I understood everything... :slight_smile:
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

3

Hi all

< stuff about changing configure snipped >

Just a reminder that we should keep in mind that we should not be making
changes to the configure script but to configure.in as Eric has
suggested in another thread.

--
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!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

On Tue, Nov 21, 2000 at 06:39:12PM +0100, Bernhard Reiter wrote:

On Wed, Nov 22, 2000 at 01:37:01AM +0900, GRASS wrote:
> From: Jan-Oliver Wagner <jan@intevation.de>
> Subject: Re: [GRASS5] Re: bug in configure routine
> > > Hmm, yes you're right. You can use --with-bindir instead of --bindir.
> >
> > Yes, I have done that to compile GRASS :slight_smile:
> >
> > > $bindir, created by --bindir, is not used though defined.
> > > $BINDIR, created by --with-bindir, is used instead.
> > >
> > > So i suggest to remove --bindir and other unused options of configure.
> > > Any objection?
> >
> > The configure environment should just behave in a general way
> > (as it is widely used) and be consistent.
> >
> > Jan
> >
>
> OK, however, those options do not work right now.
> If we want to be consistent, those options should be fixed to work correctly.
> In this case, what should be used if --bindir and --with-bindir both given?

Remove --with-bindir
and make --bindir work.

If I understood everything... :slight_smile:
  Bernhard

They're both there for the moment (in configure.in). --with-bindir will currently override
--bindir. However, configure.in is still missing many things that got
hacked into configure directly. I'm working on fixing configure.in, but
this black art takes time (and people say C pointers are hard!).

Sorry to all if I've temporarily screwed up the build system for you.
If anyone wants to work on tests for the following items, feel free:

o Auto test/search and *confirm* TIFF library support (after
  --with-tiff, is processed but before AC_SUBST()).
o Auto test/search and *confirm* TCL/TK (like tiff stuff)
o Need all of Mesa/OpenGL.
o Need all of PostgreSQL.
o Need ODBC/iODBC.
o Need DLLLIB (empty except for CygWin ?)
o Others ???

I'll work on this some more tomorrow...

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

Hi Eric

"Eric G . Miller" wrote:

o Auto test/search and *confirm* TIFF library support (after
  --with-tiff, is processed but before AC_SUBST()).
o Auto test/search and *confirm* TCL/TK (like tiff stuff)
o Need all of Mesa/OpenGL.
o Need all of PostgreSQL.
o Need ODBC/iODBC.
o Need DLLLIB (empty except for CygWin ?)
o Others ???

How about

o XDRLIB empty for SGI machines
o Test for jpeg library
o Test for png library

Also, is there a way to get configure to search in directories unique to
systems? For example on SGI the png and jpeg libraries are not installed
by default but can be easily installed under a directory called
/usr/freeware from their website. Is there a way to tell configure to
search /usr/freeware if the machine is an SGI? Or do we need to provide
an option to indicate which directory to search?

Thanks alot for taking up the configure mess. I'm sure all of us
"configure brain dead" people greatly appreciate it. I know I do.

--
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!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

On Wed, Nov 22, 2000 at 11:17:27AM +0700, Justin Hickey wrote:

Hi all

< stuff about changing configure snipped >

Just a reminder that we should keep in mind that we should not be making
changes to the configure script but to configure.in as Eric has
suggested in another thread.

Thanks Justin, several things have to be migrated to configure.in:

DLLIB,
TIFF_INCLUDE_DIRS, TIFF_LIBRARY_DIRS,
TCLDIR, TKDIR, TCLINCDIR, TKINCDIR, TCLTKLIBS,
OPENGLINC, OPENGLwINC, OPENGLLIB, OPENGLULIB, LGLWM,
PQINCPATH, PQLIBPATH, PQLIB,
ODBCINC,
SRCDIR,
ARCH

Volunteers wanted!

Regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

On Wed, Nov 22, 2000 at 02:51:39PM +0700, Justin Hickey wrote:

Hi Eric

"Eric G . Miller" wrote:
> o Auto test/search and *confirm* TIFF library support (after
> --with-tiff, is processed but before AC_SUBST()).
> o Auto test/search and *confirm* TCL/TK (like tiff stuff)
> o Need all of Mesa/OpenGL.
> o Need all of PostgreSQL.
> o Need ODBC/iODBC.
> o Need DLLLIB (empty except for CygWin ?)
> o Others ???

How about

o XDRLIB empty for SGI machines

SGI doesn't have XDRLIB? It's required for encoding rasters. Anyway, if
no special linking is needed for this, then $(XDRLIB) should evaluate to
an empty string. Currently I have it set for the three -lsun, -lnsl,
and -lrpclib (if they exist). Otherwise it now should come up empty.

o Test for jpeg library

Okay, it's on TODO list.

o Test for png library

DITTO.

Also, is there a way to get configure to search in directories unique to
systems? For example on SGI the png and jpeg libraries are not installed
by default but can be easily installed under a directory called
/usr/freeware from their website. Is there a way to tell configure to
search /usr/freeware if the machine is an SGI? Or do we need to provide
an option to indicate which directory to search?

The "common" search directories can be looked for. There's also the
--with-includes and --with-libs directives. I wasn't aware of this
/usr/freeware separation with SGI.

Thanks alot for taking up the configure mess. I'm sure all of us
"configure brain dead" people greatly appreciate it. I know I do.

Well, I wouldn't say I'm not "configure brain dead" as well. Just
learning on the "job". If any experienced "configure" people want to
stand up, the help would be appreciated :wink:

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

Hi Eric

"Eric G . Miller" wrote:

On Wed, Nov 22, 2000 at 02:51:39PM +0700, Justin Hickey wrote:
> How about
>
> o XDRLIB empty for SGI machines

SGI doesn't have XDRLIB? It's required for encoding rasters. Anyway,
if no special linking is needed for this, then $(XDRLIB) should
evaluate to an empty string. Currently I have it set for the three
-lsun, -lnsl, and -lrpclib (if they exist). Otherwise it now should
come up empty.

Yeah it's strange. On SGI, the XDRLIB is usually -lsun, however, I
noticed that a lot of modules were indicating that -lsun wasn't being
used when I was compiling. So to determine which modules were dependent
on XDRLIB I went into the head file and made XDRLIB empty, and then did
a full compilation. Strangely enough, all the modules compiled without
any errors. That means that for SGI anyway, XDRLIB is not necessary. I
have no idea why it is not needed since obviously people have been
adding it for other machines - hence some functions in Grass need it.
Strange. Thus, it would be great if configure could set XDRLIB to empty
instead of -lsun for SGI's.

> Also, is there a way to get configure to search in directories
> unique to systems? For example on SGI the png and jpeg libraries are
> not installed by default but can be easily installed under a
> directory called /usr/freeware from their website. Is there a way to
> tell configure to search /usr/freeware if the machine is an SGI? Or
> do we need to provide an option to indicate which directory to
> search?

The "common" search directories can be looked for. There's also the
--with-includes and --with-libs directives. I wasn't aware of this
/usr/freeware separation with SGI.

Yeah, SGI has a page on their website for precompiled binaries of
freeware (most of the GNU programs are there along with a lot of other
stuff). But they bundle it into distributions that have pre-determined
target directories, in this case /usr/freeware. I assume the
--with-includes and --with-libs directives simply add on their values to
the default search paths? We'll have to put this in an IRIX FAQ or
something once we get configure working decently.

Oh yeah, do you recall that there is a dependency on some library for
r.in.gdal? I seem to recall reading a message indicating this, but I'm
not sure. Just thought I'd mention it.

Talk to you later.
--
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!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

Hi Eric,

i am not an autoconf expert, but i gained some expirience in
hand-crafting the header files for IRIX and the cygwin setup.

Should i send you the header.* files so that you can see which
setups/paths work?

cu,

Andreas

Eric G . Miller wrote:

On Wed, Nov 22, 2000 at 02:51:39PM +0700, Justin Hickey wrote:
> Hi Eric
>
> "Eric G . Miller" wrote:
> > o Auto test/search and *confirm* TIFF library support (after
> > --with-tiff, is processed but before AC_SUBST()).
> > o Auto test/search and *confirm* TCL/TK (like tiff stuff)
> > o Need all of Mesa/OpenGL.
> > o Need all of PostgreSQL.
> > o Need ODBC/iODBC.
> > o Need DLLLIB (empty except for CygWin ?)
> > o Others ???
>
> How about
>
> o XDRLIB empty for SGI machines

SGI doesn't have XDRLIB? It's required for encoding rasters. Anyway, if
no special linking is needed for this, then $(XDRLIB) should evaluate to
an empty string. Currently I have it set for the three -lsun, -lnsl,
and -lrpclib (if they exist). Otherwise it now should come up empty.

I watched this too on IRIX. But i think that if there is a library of
that name (libsun? libnsl??, can't remember) the inclusion would not
hurt.
There are many messages in the form "libxyz not used to resolve any
symbol...".
Does that mean that the library is linked into the binary even if it is
not used to resolve anything? That would bloat the executable.

> o Test for jpeg library

Okay, it's on TODO list.

> o Test for png library

DITTO.

> Also, is there a way to get configure to search in directories unique to
> systems? For example on SGI the png and jpeg libraries are not installed
> by default but can be easily installed under a directory called
> /usr/freeware from their website. Is there a way to tell configure to
> search /usr/freeware if the machine is an SGI? Or do we need to provide
> an option to indicate which directory to search?

On IRIX there seems to be a difference if you use MIPS PRO native SGI
compiler or gcc. Using gcc i have always the problem that the libraries
are found in lib, but in lib the library is in the old format, whilst
gcc compiles in the new (n32 ABI) format. So the library search path
must be lib32 (/usr/lib32, /usr/local/lib32, /usr/freeware/lib32). If
you have a 64bit machine and compile in the new 64bit mode, you'll find
the libraries in lib64, but i expect this not to work without heavy code
modification.

The "common" search directories can be looked for. There's also the
--with-includes and --with-libs directives. I wasn't aware of this
/usr/freeware separation with SGI.

> Thanks alot for taking up the configure mess. I'm sure all of us
> "configure brain dead" people greatly appreciate it. I know I do.

Well, I wouldn't say I'm not "configure brain dead" as well. Just
learning on the "job". If any experienced "configure" people want to
stand up, the help would be appreciated :wink:

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

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

On Thu, Nov 23, 2000 at 01:55:54PM +0700, Justin Hickey wrote:

Hi Eric

"Eric G . Miller" wrote:
> On Wed, Nov 22, 2000 at 02:51:39PM +0700, Justin Hickey wrote:
> > How about
> >
> > o XDRLIB empty for SGI machines
>
> SGI doesn't have XDRLIB? It's required for encoding rasters. Anyway,
> if no special linking is needed for this, then $(XDRLIB) should
> evaluate to an empty string. Currently I have it set for the three
> -lsun, -lnsl, and -lrpclib (if they exist). Otherwise it now should
> come up empty.

Yeah it's strange. On SGI, the XDRLIB is usually -lsun, however, I
noticed that a lot of modules were indicating that -lsun wasn't being
used when I was compiling. So to determine which modules were dependent

Does the -lsun "not used" or whatever break the compile or is it just an
informative message? I'm not sure, but I'd think most modules don't
need it, but libgis.a does. If libgis.a already has the XDRLIB compiled
in statically, then maybe the linker just refuses to include it twice
(good!). But where it is not built into libgis.a, not having the flag
will cause libgis.a to fail. If it doesn't break the compile, I'd
rather leave it in for now. Seems at least libgis.a would need it, even
if the modules don't??? Maybe the functions or XDRLIB are built into
SGI's C library? I could put in a check before the checks for XDRLIB if
that is the case. Then I'd feel comfortable allowing XDRLIB to be
empty.

> The "common" search directories can be looked for. There's also the
> --with-includes and --with-libs directives. I wasn't aware of this
> /usr/freeware separation with SGI.

Yeah, SGI has a page on their website for precompiled binaries of
freeware (most of the GNU programs are there along with a lot of other
stuff). But they bundle it into distributions that have pre-determined
target directories, in this case /usr/freeware. I assume the
--with-includes and --with-libs directives simply add on their values to
the default search paths? We'll have to put this in an IRIX FAQ or
something once we get configure working decently.

I'm trying to put in some hooks, so that if the --with-includes and/or
--with-libs directives are used, later searches for headers/functions
will use those extra paths. I think I need to move that to before all
of the other checks.

Oh yeah, do you recall that there is a dependency on some library for
r.in.gdal? I seem to recall reading a message indicating this, but I'm
not sure. Just thought I'd mention it.

Needs Frank's libgdal (or some such name). I haven't had a chance to
try it out (suppose I should, since it seems to afford alot of
functionality).

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

On Thu, Nov 23, 2000 at 03:08:58PM +0100, Andreas Lange wrote:

Hi Eric,

i am not an autoconf expert, but i gained some expirience in
hand-crafting the header files for IRIX and the cygwin setup.

Should i send you the header.* files so that you can see which
setups/paths work?

Sure.

> SGI doesn't have XDRLIB? It's required for encoding rasters. Anyway, if
> no special linking is needed for this, then $(XDRLIB) should evaluate to
> an empty string. Currently I have it set for the three -lsun, -lnsl,
> and -lrpclib (if they exist). Otherwise it now should come up empty.

I watched this too on IRIX. But i think that if there is a library of
that name (libsun? libnsl??, can't remember) the inclusion would not
hurt. There are many messages in the form "libxyz not used to resolve
any symbol...". Does that mean that the library is linked into the
binary even if it is not used to resolve anything? That would bloat
the executable.

Well, you all will have to give me direction here.

> > Also, is there a way to get configure to search in directories unique to
> > systems? For example on SGI the png and jpeg libraries are not installed
> > by default but can be easily installed under a directory called
> > /usr/freeware from their website. Is there a way to tell configure to
> > search /usr/freeware if the machine is an SGI? Or do we need to provide
> > an option to indicate which directory to search?

On IRIX there seems to be a difference if you use MIPS PRO native SGI
compiler or gcc. Using gcc i have always the problem that the libraries
are found in lib, but in lib the library is in the old format, whilst
gcc compiles in the new (n32 ABI) format. So the library search path
must be lib32 (/usr/lib32, /usr/local/lib32, /usr/freeware/lib32). If
you have a 64bit machine and compile in the new 64bit mode, you'll find
the libraries in lib64, but i expect this not to work without heavy code
modification.

No idea about this either.

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

12

Hi Eric

"Eric G . Miller" wrote:

On Thu, Nov 23, 2000 at 01:55:54PM +0700, Justin Hickey wrote:
> Yeah it's strange. On SGI, the XDRLIB is usually -lsun, however, I
> noticed that a lot of modules were indicating that -lsun wasn't
> being used when I was compiling. So to determine which modules were
> dependent

Does the -lsun "not used" or whatever break the compile or is it just
an informative message? I'm not sure, but I'd think most modules
don't need it, but libgis.a does. If libgis.a already has the XDRLIB
compiled in statically, then maybe the linker just refuses to include
it twice (good!). But where it is not built into libgis.a, not having
the flag will cause libgis.a to fail. If it doesn't break the
compile, I'd rather leave it in for now. Seems at least libgis.a
would need it, even if the modules don't??? Maybe the functions or
XDRLIB are built into SGI's C library? I could put in a check before
the checks for XDRLIB if that is the case. Then I'd feel comfortable
allowing XDRLIB to be empty.

The libgis.a library compiles and links without error. I checked out the
current CVS, ran configure, and then deleted the -lsun option for XDRLIB
from the head file. Then I ran make install and src/libes/gis did not
report any errors. I don't know why it didn't fail. Perhaps you are
right about the necessary functions being in SGI's standard C library.
Do you know what functions those are?

Here are the modules that caused errors

Module source code not installed: html (ignored)
Module source code not installed: src/general/g.version (ignored)
Module source code not installed: src/raster/r.in.gdal (ignored)
Module source code not installed: src/raster/r.in.png (ignored)
Module source code not installed: src/raster/r.out.png (ignored)
Module source code not installed: src/raster/r.tiff (ignored)
Module source code not installed: src/sites/s.qcount (ignored)
Module source code not installed: src.contrib/UCB/gdbase (ignored)

None of the errors in these modules seem to be caused by the missing
XDRLIB option. Let me know if you want me to try for a clean compile.

--
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!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

13

Hi Justin,

On Fri, Nov 24, 2000 at 01:46:27PM +0700, Justin Hickey wrote:
[...]

Here are the modules that caused errors

Please post the error messages...

Module source code not installed: html (ignored)
Module source code not installed: src/general/g.version (ignored)

both compile on Linux.
Comment: g.version: the "cat" approach was not very portable.

Module source code not installed: src/raster/r.in.gdal (ignored)

compiles on Linux. (note: needs -ldl, which was set by configure)

Module source code not installed: src/raster/r.in.png (ignored)
Module source code not installed: src/raster/r.out.png (ignored)

Maybe still a problem of the #includes?
compiles on Linux.

Module source code not installed: src/raster/r.tiff (ignored)

I have changed Gmakefile: -z -> $(ZLIB), reordered MATHLIB XDRLIB,
removed double MATHLIB entry.
compiles on Linux.

Module source code not installed: src/sites/s.qcount (ignored)

compiles on Linux.

Module source code not installed: src.contrib/UCB/gdbase (ignored)

I have fixed the Gmakefile.
compiles on Linux *now*

Yours

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

14

Hi,

just some comments on comments:

Markus Neteler wrote:

Hi Justin,

On Fri, Nov 24, 2000 at 01:46:27PM +0700, Justin Hickey wrote:
[...]
> Here are the modules that caused errors
Please post the error messages...

> Module source code not installed: html (ignored)

depends on perl in /usr/bin/perl.
Compiles on Cygwin after creating a link from /usr/local/bin/perl to
/usr/bin/perl.
IRIX: if perl is installed, create the link. I remember perl is perl4 on
older IRIX systems, perhaps will not work with newer scripts.

> Module source code not installed: src/general/g.version (ignored)
both compile on Linux.
Comment: g.version: the "cat" approach was not very portable.

sorry for that, but i think that it is portable. Ever seen a Unix
without 'cat'? I have a fix that uses sed.

> Module source code not installed: src/raster/r.in.gdal (ignored)
compiles on Linux. (note: needs -ldl, which was set by configure)

needs external gdal library of Frank Warmerdam.
This should be asked with the configure script/get a commandline switch:
--with-gdal=/path ...

> Module source code not installed: src/raster/r.in.png (ignored)
> Module source code not installed: src/raster/r.out.png (ignored)
Maybe still a problem of the #includes?
compiles on Linux.

Still needs the netpbm-headers, which are _not_ included in the binary
distributions for Windows and IRIX. Had this problem too, copied over
the headers from my linux machine.
Markus, i'll send you a tarball of the header files. Please check if
there are licensing issues when putting this on the server.

> Module source code not installed: src/raster/r.tiff (ignored)
I have changed Gmakefile: -z -> $(ZLIB), reordered MATHLIB XDRLIB,
removed double MATHLIB entry.
compiles on Linux.

? what was the error? Perhaps unusual directory for libtiff?
IRIX has installed an older libtiff in the X11 directory, which will not
work. Needs libtiff from the freeware dist: /usr/freeware/lib32

> Module source code not installed: src/sites/s.qcount (ignored)
compiles on Linux.

??

> Module source code not installed: src.contrib/UCB/gdbase (ignored)
I have fixed the Gmakefile.
compiles on Linux *now*

Is this part of the GRASS list?

yours,

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

15

On Fri, Nov 24, 2000 at 01:46:27PM +0700, Justin Hickey wrote:

The libgis.a library compiles and links without error. I checked out the
current CVS, ran configure, and then deleted the -lsun option for XDRLIB
from the head file. Then I ran make install and src/libes/gis did not
report any errors. I don't know why it didn't fail. Perhaps you are
right about the necessary functions being in SGI's standard C library.
Do you know what functions those are?

xdrmem_create(), xdr_float(), xdr_double(), xdr_proc() not sure what
else. Mostly it seems restricted to floating point rasters. CELL type
rasters are encoded and compressed differently. I don't know that
anything else uses the xdr stuff.

Here are the modules that caused errors

Module source code not installed: html (ignored)
Module source code not installed: src/general/g.version (ignored)
Module source code not installed: src/raster/r.in.gdal (ignored)
Module source code not installed: src/raster/r.in.png (ignored)
Module source code not installed: src/raster/r.out.png (ignored)
Module source code not installed: src/raster/r.tiff (ignored)
Module source code not installed: src/sites/s.qcount (ignored)
Module source code not installed: src.contrib/UCB/gdbase (ignored)

None of the errors in these modules seem to be caused by the missing
XDRLIB option. Let me know if you want me to try for a clean compile.

No, I don't think they are related either.

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

16

Hi again,

On Fri, Nov 24, 2000 at 09:01:58PM +0100, Andreas Lange wrote:

Hi,
just some comments on comments:

> > Module source code not installed: html (ignored)
depends on perl in /usr/bin/perl.
Compiles on Cygwin after creating a link from /usr/local/bin/perl to
/usr/bin/perl.
IRIX: if perl is installed, create the link. I remember perl is perl4 on
older IRIX systems, perhaps will not work with newer scripts.

Perhaps an issue for "configure.in": find the PERL location?!

[useful comments removed]

> > Module source code not installed: src/raster/r.out.png (ignored)
Still needs the netpbm-headers, which are _not_ included in the binary
distributions for Windows and IRIX. Had this problem too, copied over
the headers from my linux machine.
Markus, i'll send you a tarball of the header files. Please check if
there are licensing issues when putting this on the server.

O.k.

> > Module source code not installed: src.contrib/UCB/gdbase (ignored)
> I have fixed the Gmakefile.
> compiles on Linux *now*
Is this part of the GRASS list?

It was because of s.reclass which is in src/scripts/.. now. I have commented
it now in src/CMD/lists/GRASS.

Thanks for your comments, Andreas,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

17

On Sat, Nov 25, 2000 at 06:45:21PM +0000, Markus Neteler wrote:

Hi again,

On Fri, Nov 24, 2000 at 09:01:58PM +0100, Andreas Lange wrote:
> Hi,
> just some comments on comments:
>
> > > Module source code not installed: html (ignored)
> depends on perl in /usr/bin/perl.
> Compiles on Cygwin after creating a link from /usr/local/bin/perl to
> /usr/bin/perl.
> IRIX: if perl is installed, create the link. I remember perl is perl4 on
> older IRIX systems, perhaps will not work with newer scripts.

Perhaps an issue for "configure.in": find the PERL location?!

Possibly, but the perl script would have to be generated with an "in"
file, with first line like:

#! $(PERL)

Let me know if this is something we want to do. With all of perl's magic
though, there could be problems with unintended variable expansion.
Maybe better just to have a separate little function generate the magic
line (does that magic work under Windows?).

[useful comments removed]
> > > Module source code not installed: src/raster/r.out.png (ignored)
> Still needs the netpbm-headers, which are _not_ included in the binary
> distributions for Windows and IRIX. Had this problem too, copied over
> the headers from my linux machine.
> Markus, i'll send you a tarball of the header files. Please check if
> there are licensing issues when putting this on the server.
O.k.

Debian has the netpbm separated in free and non-free. Anyway, I think
just the pnm.h header is no problem.

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

18

Hi Eric,

I have split TCLTKLIBS into TCLTKLIBPATH and TCLTKLIBS and updated
*somewhat* configure.in (just added AC_SUBST to achive an empty variable,
generally I don't want to bother you with changes in configure.in).

If you would manage to add this:
TCLTKLIBS = -ltk8.3 -ltcl8.3 # or whatever version
TCLTKLIBPATH = -L/usr/lib # or whatever path

it would be perfect. I have updated the NVIZ2.2/src/Gmakefile already
to reflect this.

On Sat, Nov 25, 2000 at 12:23:41PM -0800, Eric G . Miller wrote:

On Sat, Nov 25, 2000 at 06:45:21PM +0000, Markus Neteler wrote:
> On Fri, Nov 24, 2000 at 09:01:58PM +0100, Andreas Lange wrote:
> > > > Module source code not installed: html (ignored)
> > depends on perl in /usr/bin/perl.
> > Compiles on Cygwin after creating a link from /usr/local/bin/perl to
> > /usr/bin/perl.
> > IRIX: if perl is installed, create the link. I remember perl is perl4 on
> > older IRIX systems, perhaps will not work with newer scripts.
>
> Perhaps an issue for "configure.in": find the PERL location?!

Possibly, but the perl script would have to be generated with an "in"
file, with first line like:

#! $(PERL)

Let me know if this is something we want to do. With all of perl's magic
though, there could be problems with unintended variable expansion.
Maybe better just to have a separate little function generate the magic
line (does that magic work under Windows?).

Yes, that might be right. Otherwise we would have to maintain a list of
which scripts to be changed. Mhhh...
  
Regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

19

On Wed, Nov 22, 2000 at 02:51:39PM +0700, Justin Hickey wrote:

How about

o XDRLIB empty for SGI machines

Added a test in configure.in for this *and* noticed that glibc2.2 also
has the xdr functions built into it (I didn't see this in the Libc
documentation, but there they are!).

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'