[GRASS-dev] G_OPT_R_OUTPUT base or output?

GRASS GRASS developer
,
1

On two very similar systems built today from the RC6 tarball (i686 RHEL5, F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the traditional "output" on RHEL5. The tarballs have the same md5sums. Why?

r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.

lib/gis/parser.c sets Opt->key to "output" in both, and G_OPT_R_BASE is a different entry in the enum definition. I find this puzzling ...

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

2

On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On two very similar systems built today from the RC6 tarball (i686 RHEL5,
F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
traditional "output" on RHEL5. The tarballs have the same md5sums. Why?

r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.

lib/gis/parser.c sets Opt->key to "output" in both, and G_OPT_R_BASE is a
different entry in the enum definition. I find this puzzling ...

Roger

Hi Roger,

Did you do a:

make distclean

before compiling the source?

Cheers,

Dylan

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

3

On Wed, 16 Apr 2008, Dylan Beaudette wrote:

On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On two very similar systems built today from the RC6 tarball (i686 RHEL5,
F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
traditional "output" on RHEL5. The tarballs have the same md5sums. Why?

r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.

lib/gis/parser.c sets Opt->key to "output" in both, and G_OPT_R_BASE is a
different entry in the enum definition. I find this puzzling ...

Roger

Hi Roger,

Did you do a:

make distclean

before compiling the source?

Hi,

I used the tarball, and untarred to a fresh directory. Should I still have said make distclean? I'll try - but why the different behaviour? The windows native binary is "output".

Best wishes,

Roger

Cheers,

Dylan

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

4

On Wed, Apr 16, 2008 at 7:47 AM, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On Wed, 16 Apr 2008, Dylan Beaudette wrote:

> On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <Roger.Bivand@nhh.no> wrote:
>
> > On two very similar systems built today from the RC6 tarball (i686
RHEL5,
> > F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
> > traditional "output" on RHEL5. The tarballs have the same md5sums. Why?
> >
> > r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.
> >
> > lib/gis/parser.c sets Opt->key to "output" in both, and G_OPT_R_BASE is
a
> > different entry in the enum definition. I find this puzzling ...
> >
> > Roger
> >
>
> Hi Roger,
>
> Did you do a:
>
> make distclean
>
> before compiling the source?
>

Hi,

I used the tarball, and untarred to a fresh directory. Should I still have
said make distclean? I'll try - but why the different behaviour? The windows
native binary is "output".

Best wishes,

Roger

I have seen / heard / read that a make distclean can be of use-- but I
think that I spoke too soon. It is usually related to re-compiling
only portions of the source. Not sure what it could be.

Dylan

>
> Cheers,
>
> Dylan
>
>
>
> >
> > --
> > Roger Bivand
> > Economic Geography Section, Department of Economics, Norwegian School
of
> > Economics and Business Administration, Helleveien 30, N-5045 Bergen,
> > Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
> > e-mail: Roger.Bivand@nhh.no
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
> >
> >
>
>

--

Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

5

Roger Bivand wrote:

On Wed, 16 Apr 2008, Dylan Beaudette wrote:

On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On two very similar systems built today from the RC6 tarball (i686 RHEL5,
F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
traditional "output" on RHEL5. The tarballs have the same md5sums. Why?

r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.

lib/gis/parser.c sets Opt->key to "output" in both, and G_OPT_R_BASE is a
different entry in the enum definition. I find this puzzling ...

Roger

Hi Roger,

Did you do a:

make distclean

before compiling the source?

Hi,

I used the tarball, and untarred to a fresh directory. Should I still have said make distclean? I'll try - but why the different behaviour? The windows native binary is "output".

Dear Roger,

on a fresh tarball "make distclean" isn't needed.
I suspect that your binaries pick a wrong library. Could
you check with "ldd"?
I am using the release branch in production and didn't come
across this problem.

Markus

6

On Wed, 16 Apr 2008, Markus Neteler wrote:

Roger Bivand wrote:

On Wed, 16 Apr 2008, Dylan Beaudette wrote:

> On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <Roger.Bivand@nhh.no> > wrote:
> > On two very similar systems built today from the RC6 tarball (i686 > > RHEL5,
> > F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
> > traditional "output" on RHEL5. The tarballs have the same md5sums. > > Why?
> > > > r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.
> > > > lib/gis/parser.c sets Opt->key to "output" in both, and G_OPT_R_BASE > > is a
> > different entry in the enum definition. I find this puzzling ...
> > > > Roger
> > Hi Roger,
> > Did you do a:
> > make distclean
> > before compiling the source?

Hi,

I used the tarball, and untarred to a fresh directory. Should I still have
said make distclean? I'll try - but why the different behaviour? The
windows native binary is "output".

Dear Roger,

on a fresh tarball "make distclean" isn't needed.
I suspect that your binaries pick a wrong library. Could
you check with "ldd"?
I am using the release branch in production and didn't come
across this problem.

This is possible - both affected systems, the F7 system refered to above - documented here:

GRASS 6.3.0RC6 (spearfish60):~ > r.in.bin --interface-description
<?xml version="1.0" encoding="ANSI_X3.4-1968"?>
<!DOCTYPE task SYSTEM "grass-interface.dtd">
<task name="r.in.bin">
         <description>
...
         </parameter>
         <parameter name="output" type="string" required="yes" multiple="no">
                 <description>
                         Name for output raster map
                 </description>
...

GRASS 6.3.0RC6 (spearfish60):~ > R

R version 2.6.2 (2008-02-08)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
...

system("r.in.bin --interface-description")

<?xml version="1.0" encoding="ANSI_X3.4-1968"?>
<!DOCTYPE task SYSTEM "grass-interface.dtd">
<task name="r.in.bin">
         <description>
...
         </parameter>
         <parameter name="base" type="string" required="yes" multiple="no">
                 <description>
                         Name of base raster map
                 </description>
...

and an odd problem on a Cygwin 6.2.3 installation
(key modules do not write to stderr or stdout, documented in: http://spatial.nhh.no/misc/cw.png) - problem started after updating cygwin packages last night,

have odd/stale things in the GRASS_LD_LIBRARY_PATH and in PATH (or LD path) environment variables. I don't have ldd on Cygwin, but will look under F7.

I was just checking a few extra systems to see how the R interface worked on the final RC before release, that's why I'm asking.

Roger

Markus

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

7

Roger Bivand wrote:

I don't have ldd on Cygwin, but will look under F7.

use cygcheck,

http://grass.osgeo.org/grass62/binary/mswindows/#trouble

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

8

Roger Bivand wrote:

have odd/stale things in the GRASS_LD_LIBRARY_PATH and in PATH (or LD
path) environment variables. I don't have ldd on Cygwin, but will look
under F7.

On Cygwin, "cygcheck" lists the DLLs which a program uses.

--
Glynn Clements <glynn@gclements.plus.com>

9

On Wed, 16 Apr 2008, Hamish wrote:

Roger Bivand wrote:

I don't have ldd on Cygwin, but will look under F7.

use cygcheck,

http://grass.osgeo.org/grass62/binary/mswindows/#trouble

Thanks to Hamish and Glynn - making a copy of the installed /bin/cygjasper-1.dll as /bin/cygjasper-1-701-1.dll (which cygcheck showed to be missing) appears to resolve the problem.

The F7 problems were the result of intrusive debris lying around from trying to build QGIS without success a little while ago. So ldd did resolve it in less than 10 rounds.

Roger

Hamish

     ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no