[GRASS5] current WinGRASS binaries compiled without PNG?

I've been trying to track down a PNG problem with GRASS for CYGWIN binaries downloaded from the main WinGRASS download site. When d.mon start=PNG is invoked, it returns the following error:

ERROR: no such monitor 'PNG"
No such monitor as 'PNG'
Problem selecting PNG. Will try once more
No such monitor as 'PNG'

My read is that this indicates the binaries were compiled -without PNG.

Is this correct?

If, so, can new binaries be compiled with PNG? Is PNG a problem for WinGRASS?

Thanks very much for your help.

Michael Barton
______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671

Michael Barton wrote:

I've been trying to track down a PNG problem with GRASS for CYGWIN binaries downloaded from the main WinGRASS download site. When d.mon start=PNG is invoked, it returns the following error:

ERROR: no such monitor 'PNG"
No such monitor as 'PNG'
Problem selecting PNG. Will try once more
No such monitor as 'PNG'

My read is that this indicates the binaries were compiled -without PNG.

Is this correct?

If, so, can new binaries be compiled with PNG? Is PNG a problem for WinGRASS?

Thanks very much for your help.

Michael Barton

I think I compiled the 5.0.3 binaries at:
  http://grass.ibiblio.org/grass5/binary/windows_cygnus/wingrass_xserver/
And it was compiled with PNG support (see grass5.0.3_config.log in above directory). I have not occasion to use the PNG driver under Cygwin, but I just gave it a try and received the same error message you got.

Sorry that doesn't help you much.

--
Richard Greenwood
www.greenwoodmap.com

Richard Greenwood wrote:

> I've been trying to track down a PNG problem with GRASS for CYGWIN
> binaries downloaded from the main WinGRASS download site. When d.mon
> start=PNG is invoked, it returns the following error:
>
> ERROR: no such monitor 'PNG"
> No such monitor as 'PNG'
> Problem selecting PNG. Will try once more
> No such monitor as 'PNG'
>
> My read is that this indicates the binaries were compiled -without PNG.
>
> Is this correct?
>
> If, so, can new binaries be compiled with PNG? Is PNG a problem for
> WinGRASS?
>
> Thanks very much for your help.
>
> Michael Barton

I think I compiled the 5.0.3 binaries at:
  http://grass.ibiblio.org/grass5/binary/windows_cygnus/wingrass_xserver/
And it was compiled with PNG support (see grass5.0.3_config.log in above
directory).

The config.log file says:

GD support: no

This means that the PNG driver won't have been built. PNG support
alone is sufficient for r.in.png and r.out.png, but the PNG driver
also requires GD (this dependency has recently been removed in 5.3).

[Actually, the PNG driver only uses PNG if GD uses PNG. The GD library
which is shipped with RedHat 6.2 uses GIF rather than PNG; in that
situation, you don't need the PNG library, and the PNG driver produces
GIF images instead of PNG images.]

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

Glynn Clements wrote:

Richard Greenwood wrote:

I've been trying to track down a PNG problem with GRASS for CYGWIN binaries downloaded from the main WinGRASS download site. When d.mon start=PNG is invoked, it returns the following error:

ERROR: no such monitor 'PNG"
No such monitor as 'PNG'
Problem selecting PNG. Will try once more
No such monitor as 'PNG'

My read is that this indicates the binaries were compiled -without PNG.

Is this correct?

If, so, can new binaries be compiled with PNG? Is PNG a problem for WinGRASS?

Thanks very much for your help.

Michael Barton

I think I compiled the 5.0.3 binaries at:
http://grass.ibiblio.org/grass5/binary/windows_cygnus/wingrass_xserver/
And it was compiled with PNG support (see grass5.0.3_config.log in above directory).

The config.log file says:

GD support: no

This means that the PNG driver won't have been built. PNG support
alone is sufficient for r.in.png and r.out.png, but the PNG driver
also requires GD (this dependency has recently been removed in 5.3).

Glynn - thanks for the explanation. I will try to get a new build together with GD as soon as I find time.

Rich

[Actually, the PNG driver only uses PNG if GD uses PNG. The GD library
which is shipped with RedHat 6.2 uses GIF rather than PNG; in that
situation, you don't need the PNG library, and the PNG driver produces
GIF images instead of PNG images.]

--
Richard Greenwood
www.greenwoodmap.com

A couple things, neither is good news.

1. Building 5.3 under Cygwin was successful with the 2004_01_03 snapshot, however the 2004_01_10 and 2004_02_28 snapshots both fail in configure as follows:

checking whether to use Tcl/Tk... yes
checking for location of Tcl/Tk includes...
checking for tcl.h... yes
checking for tk.h... yes
checking Tcl version... 8.3
checking Tk version... 8.3
checking for location of Tcl/Tk library... /usr/local/lib/tcl8.3
checking for Tcl_Init in -ltcl... no
checking for Tcl_Init in -ltcl8.3... no
checking for Tcl_Init in -ltcl83... no
configure: error: *** Unable to locate Tcl library.

Is it possible that something changed in the 5.3 source between
January 3 and 10 that would cause this?

Although 5.3 did build, when running the Tck/Tk interface, I am unable to close any of the dialog boxes. I do not consider it to run well enough to be worth distributing, but Michael Barton had expressed interest in a 5.3 binary distribution, and I am happy to make it available if he or anyone else would like it.
  
2. I have tried Glynn’s Cygwin NVWISH2.2 dated 3/3/2004 under both 5.0.3 and 5.3. Three panels open momentarily before the error pasted at the bottom of this email. Comparing my Cygwin configuration with Glynn’s, a notable difference is that I am using Xfree 4.3 while Glynn has 4.2 and I have not been able to find 4.2 binary installations files to test with.

A couple very general comments: Until recently I have always run GRASS under Cygwin from the command prompt, rather than Tcl/Tk (and I have only run Nviz under Linux). From the command prompt GRASS has run entirely reliably and given me very good service, but these Tcl/Tk problems are beyond my current ability to contribute much assistance with.

==== 3/3/2004 NVWISH2.2 error message ====

Error in startup script: integer value too large to represent
     while executing
"expr int([lindex $range 0])"
     (procedure "mkcutplanePanel" line 55)
     invoked from within
"mk$name\Panel $path"
     (procedure "Nv_force_panel" line 10)
     invoked from within
"Nv_force_panel $i"
     (procedure "Nv_mkPanelMenu" line 12)
     invoked from within
"Nv_mkPanelMenu $Nv_(AREA).menu.panel"
     (procedure "Nv_makeGUI" line 87)
     invoked from within
"Nv_makeGUI .top"
     (file "/usr/local/grass5/etc/nviz2.2/scripts/nviz2.2_script" line 696)
child process exited abnormally
     while executing
"exec /usr/local/grass5/etc/nviz2.2/NVWISH2.2 -f /usr/local/grass5/etc/nviz2.2/s
cripts/nviz2.2_script -q -name NVIZ >&@stdout"
     ("eval" body line 1)
     invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scri
pts/nviz2.2_script $argv -name NVIZ >&@stdout"
     invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scrip
ts/nviz2.2_script -name NVIZ >&@stdo..."
     (file "/usr/local/grass5/bin/nviz" line 16)

--
Richard Greenwood
www.greenwoodmap.com

Richard Greenwood wrote:

A couple things, neither is good news.

1. Building 5.3 under Cygwin was successful with the 2004_01_03
snapshot, however the 2004_01_10 and 2004_02_28 snapshots both fail in
configure as follows:

checking whether to use Tcl/Tk... yes
checking for location of Tcl/Tk includes...
checking for tcl.h... yes
checking for tk.h... yes
checking Tcl version... 8.3
checking Tk version... 8.3
checking for location of Tcl/Tk library... /usr/local/lib/tcl8.3
checking for Tcl_Init in -ltcl... no
checking for Tcl_Init in -ltcl... no
checking for Tcl_Init in -ltcl8.3... no
checking for Tcl_Init in -ltcl8.3... no
checking for Tcl_Init in -ltcl83... no
checking for Tcl_Init in -ltcl83... no
configure: error: *** Unable to locate Tcl library.

Is it possible that something changed in the 5.3 source between
January 3 and 10 that would cause this?

There were two changes to configure[.in] between those dates:

revision 1.120
date: 2004/01/09 19:57:05; author: glynn; state: Exp; lines: +3 -4
Don't generate makefiles in configure script
Only (re)build makefiles when necessary
----------------------------
revision 1.119
date: 2004/01/05 10:26:25; author: paul; state: Exp; lines: +46 -5
(1) Experimental shared libary support (--enable-gmake=no --enable-shared=yes)
(2) --with-gdal is now the default
(3) startup script now called grass53 (NAME_VER=53)
(4) Set LD_LIBRARY_PATH properly in Init.sh

However, neither of these directly touched the Tcl/Tk checks.

Look for the corresponding error messages in config.log.

Although 5.3 did build, when running the Tck/Tk interface, I am unable
to close any of the dialog boxes. I do not consider it to run well
enough to be worth distributing, but Michael Barton had expressed
interest in a 5.3 binary distribution, and I am happy to make it
available if he or anyone else would like it.

Which window manager are you using? twm doesn't put a "close" button
in the title bar; you have to select "Kill" from the root menu then
click on a window. This probably won't work with a rootless X server.

2. I have tried Glynn’s Cygwin NVWISH2.2 dated 3/3/2004 under both 5.0.3
and 5.3. Three panels open momentarily before the error pasted at the
bottom of this email. Comparing my Cygwin configuration with Glynn’s, a
notable difference is that I am using Xfree 4.3 while Glynn has 4.2 and
I have not been able to find 4.2 binary installations files to test with.

A couple very general comments: Until recently I have always run GRASS
under Cygwin from the command prompt, rather than Tcl/Tk (and I have
only run Nviz under Linux). From the command prompt GRASS has run
entirely reliably and given me very good service, but these Tcl/Tk
problems are beyond my current ability to contribute much assistance with.

==== 3/3/2004 NVWISH2.2 error message ====

Error in startup script: integer value too large to represent
     while executing
"expr int([lindex $range 0])"
     (procedure "mkcutplanePanel" line 55)
     invoked from within

This suggests that GS_get_zrange_nz() is returning garbage, possibly
because it can't find a surface.

It could be related to the X server, possibly to its GLX support. Can
you run the "glxinfo" and "glxgears" programs?

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

Glynn Clements wrote:

Richard Greenwood wrote:

A couple things, neither is good news.

1. Building 5.3 under Cygwin was successful with the 2004_01_03 snapshot, however the 2004_01_10 and 2004_02_28 snapshots both fail in configure as follows:

checking whether to use Tcl/Tk... yes
checking for location of Tcl/Tk includes...
checking for tcl.h... yes
checking for tk.h... yes
checking Tcl version... 8.3
checking Tk version... 8.3
checking for location of Tcl/Tk library... /usr/local/lib/tcl8.3
checking for Tcl_Init in -ltcl... no
checking for Tcl_Init in -ltcl8.3... no
checking for Tcl_Init in -ltcl83... no
configure: error: *** Unable to locate Tcl library.

Is it possible that something changed in the 5.3 source between
January 3 and 10 that would cause this?

There were two changes to configure[.in] between those dates:

revision 1.120
date: 2004/01/09 19:57:05; author: glynn; state: Exp; lines: +3 -4
Don't generate makefiles in configure script
Only (re)build makefiles when necessary
----------------------------
revision 1.119
date: 2004/01/05 10:26:25; author: paul; state: Exp; lines: +46 -5
(1) Experimental shared libary support (--enable-gmake=no --enable-shared=yes)
(2) --with-gdal is now the default
(3) startup script now called grass53 (NAME_VER=53)
(4) Set LD_LIBRARY_PATH properly in Init.sh

However, neither of these directly touched the Tcl/Tk checks.

Look for the corresponding error messages in config.log.

Here are the last couple dozen lines of my configure.log from the
2004_02_28 snapshot.

int main() {
Tcl_Init()
; return 0; }
configure:8016: checking for Tcl_Init in -ltcl83
configure:8033: gcc -o conftest -O2 -I/usr/include/ncurses
-L/usr/local/lib/tcl8.3 -Wl,--export-dynamic conftest.c -ltcl83 1>&5
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/../../../../i686-pc-cygwin/bin/ld:

cannot find -ltcl83
collect2: ld returned 1 exit status
configure: failed program was:
#line 8022 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply. */
char Tcl_Init();

int main() {
Tcl_Init()
; return 0; }
configure:8052: checking for Tcl_Init in -ltcl83
configure:8069: gcc -o conftest -O2 -I/usr/include/ncurses
-L/usr/local/lib/tcl8.3 -Wl,--export-dynamic conftest.c -ltcl83 1>&5
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/../../../../i686-pc-cygwin/bin/ld:

cannot find -ltcl83
collect2: ld returned 1 exit status
configure: failed program was:
#line 8058 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply. */
char Tcl_Init();

int main() {
Tcl_Init()
; return 0; }

Although 5.3 did build, when running the Tck/Tk interface, I am unable to close any of the dialog boxes. I do not consider it to run well enough to be worth distributing, but Michael Barton had expressed interest in a 5.3 binary distribution, and I am happy to make it available if he or anyone else would like it.

Which window manager are you using? twm doesn't put a "close" button
in the title bar; you have to select "Kill" from the root menu then
click on a window. This probably won't work with a rootless X server.

Well I wasn't using any windows manager. I was simply starting XWin.exe
and running a text mode Bash shell. So the X windows appear as standard
looking Microsoft Windows with 3 buttons on the left side of the title
bar, but 'X' having no effect when clicked.

However I launched twm, then GRASS from within twm, and as you said,
there is no kill button. But when I exited twm and re-ran GRASS from the
text mode Bash shell, the 'X' button was functional. So I need to
investigate this further on my end.

2. I have tried Glynn?s Cygwin NVWISH2.2 dated 3/3/2004 under both 5.0.3 and 5.3. Three panels open momentarily before the error pasted at the bottom of this email. Comparing my Cygwin configuration with Glynn?s, a notable difference is that I am using Xfree 4.3 while Glynn has 4.2 and I have not been able to find 4.2 binary installations files to test with.

A couple very general comments: Until recently I have always run GRASS under Cygwin from the command prompt, rather than Tcl/Tk (and I have only run Nviz under Linux). From the command prompt GRASS has run entirely reliably and given me very good service, but these Tcl/Tk problems are beyond my current ability to contribute much assistance with.

==== 3/3/2004 NVWISH2.2 error message ====

Error in startup script: integer value too large to represent
    while executing
"expr int([lindex $range 0])"
    (procedure "mkcutplanePanel" line 55)
    invoked from within

This suggests that GS_get_zrange_nz() is returning garbage, possibly
because it can't find a surface.

It could be related to the X server, possibly to its GLX support. Can
you run the "glxinfo" and "glxgears" programs?

glxgears runs correctly. Following is the output from glxinfo:

name of display: 127.0.0.1:0.0
display: 127.0.0.1:0 screen: 0
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
     GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
     GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
     GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.3 Mesa 4.0.4
OpenGL extensions:
     GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp,
     GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
     GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
     GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color,
     GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add,
     GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
     GL_EXT_texture_lod_bias
glu version: 1.3
glu extensions:
     GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

    visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
  id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x22 16 tc 1 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x23 16 tc 1 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 None
0x24 16 tc 1 16 0 r y . 5 6 5 8 0 16 8 16 16 16 16 0 0 None
0x25 16 tc 1 16 0 r . . 5 6 5 8 0 16 8 16 16 16 16 0 0 None

--
Richard Greenwood
www.greenwoodmap.com

Richard Greenwood wrote:

>>A couple things, neither is good news.
>>
>>1. Building 5.3 under Cygwin was successful with the 2004_01_03
>>snapshot, however the 2004_01_10 and 2004_02_28 snapshots both fail in
>>configure as follows:
>>
>>checking whether to use Tcl/Tk... yes
>>checking for location of Tcl/Tk includes...
>>checking for tcl.h... yes
>>checking for tk.h... yes
>>checking Tcl version... 8.3
>>checking Tk version... 8.3
>>checking for location of Tcl/Tk library... /usr/local/lib/tcl8.3
>>checking for Tcl_Init in -ltcl... no
>>checking for Tcl_Init in -ltcl... no
>>checking for Tcl_Init in -ltcl8.3... no
>>checking for Tcl_Init in -ltcl8.3... no
>>checking for Tcl_Init in -ltcl83... no
>>checking for Tcl_Init in -ltcl83... no
>>configure: error: *** Unable to locate Tcl library.
>>
>>Is it possible that something changed in the 5.3 source between
>>January 3 and 10 that would cause this?
>
>
> There were two changes to configure[.in] between those dates:
>
> revision 1.120
> date: 2004/01/09 19:57:05; author: glynn; state: Exp; lines: +3 -4
> Don't generate makefiles in configure script
> Only (re)build makefiles when necessary
> ----------------------------
> revision 1.119
> date: 2004/01/05 10:26:25; author: paul; state: Exp; lines: +46 -5
> (1) Experimental shared libary support (--enable-gmake=no --enable-shared=yes)
> (2) --with-gdal is now the default
> (3) startup script now called grass53 (NAME_VER=53)
> (4) Set LD_LIBRARY_PATH properly in Init.sh
>
> However, neither of these directly touched the Tcl/Tk checks.
>
> Look for the corresponding error messages in config.log.

Here are the last couple dozen lines of my configure.log from the
2004_02_28 snapshot.

cannot find -ltcl83

cannot find -ltcl83

I need to see the case (assuming that their is one) which fails with a
different error. On any given system, four of the six attempts will
normally fail with a "cannot find" error.

The Tcl checks test for -ltcl, -ltcl8.3 and -ltcl83 (for the last two,
the exact version number is taken from <tcl.h>), both with and without
$DLLIB (which is set to the library which provides dlsym).

Depending upon what your Tcl library is actually called, two of the
three pairs will fail (if it's called libtcl8.3, the -ltcl and -ltcl83
pairs will fail; the -ltcl8.3 pair would be the interesting one).

>>Although 5.3 did build, when running the Tck/Tk interface, I am unable
>>to close any of the dialog boxes. I do not consider it to run well
>>enough to be worth distributing, but Michael Barton had expressed
>>interest in a 5.3 binary distribution, and I am happy to make it
>>available if he or anyone else would like it.
>
>
> Which window manager are you using? twm doesn't put a "close" button
> in the title bar; you have to select "Kill" from the root menu then
> click on a window. This probably won't work with a rootless X server.

Well I wasn't using any windows manager. I was simply starting XWin.exe
and running a text mode Bash shell. So the X windows appear as standard
looking Microsoft Windows with 3 buttons on the left side of the title
bar, but 'X' having no effect when clicked.

Using rootless mode (where each X window is a separate Windows window)
is one more source of potential problems. It would be better to use
the conventional mode (where there is a single window for the entire X
"screen") for testing.

Also, the more usual way to start the X server is with "startx".

>>2. I have tried Glynn?s Cygwin NVWISH2.2 dated 3/3/2004 under both 5.0.3
>>and 5.3. Three panels open momentarily before the error pasted at the
>>bottom of this email. Comparing my Cygwin configuration with Glynn?s, a
>>notable difference is that I am using Xfree 4.3 while Glynn has 4.2 and
>>I have not been able to find 4.2 binary installations files to test with.
>>
>>A couple very general comments: Until recently I have always run GRASS
>>under Cygwin from the command prompt, rather than Tcl/Tk (and I have
>>only run Nviz under Linux). From the command prompt GRASS has run
>>entirely reliably and given me very good service, but these Tcl/Tk
>>problems are beyond my current ability to contribute much assistance with.
>>
>>==== 3/3/2004 NVWISH2.2 error message ====
>>
>>Error in startup script: integer value too large to represent
>> while executing
>>"expr int([lindex $range 0])"
>> (procedure "mkcutplanePanel" line 55)
>> invoked from within

Hmm. That's exactly the same error which Scott reported yesterday:

  http://intevation.de/rt/webrt?serial_num=2349

That was with 5.0.3 on Linux, so this may not actually be a Cygwin
issue. He reported that it only occurred when using a specific map for
the colours. Try different options, e.g. "nviz -q".

> This suggests that GS_get_zrange_nz() is returning garbage, possibly
> because it can't find a surface.
>
> It could be related to the X server, possibly to its GLX support. Can
> you run the "glxinfo" and "glxgears" programs?

glxgears runs correctly. Following is the output from glxinfo:

That looks sensible enough.

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

Glynn Clements wrote:

Richard Greenwood wrote:

A couple things, neither is good news.

1. Building 5.3 under Cygwin was successful with the 2004_01_03 snapshot, however the 2004_01_10 and 2004_02_28 snapshots both fail in configure as follows:

checking whether to use Tcl/Tk... yes
checking for location of Tcl/Tk includes...
checking for tcl.h... yes
checking for tk.h... yes
checking Tcl version... 8.3
checking Tk version... 8.3
checking for location of Tcl/Tk library... /usr/local/lib/tcl8.3
checking for Tcl_Init in -ltcl... no
checking for Tcl_Init in -ltcl8.3... no
checking for Tcl_Init in -ltcl83... no
configure: error: *** Unable to locate Tcl library.

Is it possible that something changed in the 5.3 source between
January 3 and 10 that would cause this?

There were two changes to configure[.in] between those dates:

revision 1.120
date: 2004/01/09 19:57:05; author: glynn; state: Exp; lines: +3 -4
Don't generate makefiles in configure script
Only (re)build makefiles when necessary
----------------------------
revision 1.119
date: 2004/01/05 10:26:25; author: paul; state: Exp; lines: +46 -5
(1) Experimental shared libary support (--enable-gmake=no --enable-shared=yes)
(2) --with-gdal is now the default
(3) startup script now called grass53 (NAME_VER=53)
(4) Set LD_LIBRARY_PATH properly in Init.sh

However, neither of these directly touched the Tcl/Tk checks.

Look for the corresponding error messages in config.log.

Here are the last couple dozen lines of my configure.log from the
2004_02_28 snapshot.

cannot find -ltcl83

cannot find -ltcl83

I need to see the case (assuming that their is one) which fails with a
different error. On any given system, four of the six attempts will
normally fail with a "cannot find" error.

The Tcl checks test for -ltcl, -ltcl8.3 and -ltcl83 (for the last two,
the exact version number is taken from <tcl.h>), both with and without
$DLLIB (which is set to the library which provides dlsym).

Depending upon what your Tcl library is actually called, two of the
three pairs will fail (if it's called libtcl8.3, the -ltcl and -ltcl83
pairs will fail; the -ltcl8.3 pair would be the interesting one).

Below are the config.log results for all six tests. I should note that I and using the switch:
    --with-tcltk-libs=/usr/local/lib/tcl8.3

configure:7826: checking for location of Tcl/Tk library
configure:7856: checking for Tcl_Init in -ltcl
configure:7873: gcc -o conftest -O2 -I/usr/include/ncurses -L/usr/local/lib/tcl8.3 -Wl,--export-dynamic conftest.c -ltcl 1>&5
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/../../../../i686-pc-cygwin/bin/ld: cannot find -ltcl
collect2: ld returned 1 exit status
configure: failed program was:
#line 7862 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply. */
char Tcl_Init();

int main() {
Tcl_Init()
; return 0; }
configure:7892: checking for Tcl_Init in -ltcl
configure:7909: gcc -o conftest -O2 -I/usr/include/ncurses -L/usr/local/lib/tcl8.3 -Wl,--export-dynamic conftest.c -ltcl 1>&5
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/../../../../i686-pc-cygwin/bin/ld: cannot find -ltcl
collect2: ld returned 1 exit status
configure: failed program was:
#line 7898 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply. */
char Tcl_Init();

int main() {
Tcl_Init()
; return 0; }
configure:7936: checking for Tcl_Init in -ltcl8.3
configure:7953: gcc -o conftest -O2 -I/usr/include/ncurses -L/usr/local/lib/tcl8.3 -Wl,--export-dynamic conftest.c -ltcl8.3 1>&5
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/../../../../i686-pc-cygwin/bin/ld: cannot find -ltcl8.3
collect2: ld returned 1 exit status
configure: failed program was:
#line 7942 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply. */
char Tcl_Init();

int main() {
Tcl_Init()
; return 0; }
configure:7972: checking for Tcl_Init in -ltcl8.3
configure:7989: gcc -o conftest -O2 -I/usr/include/ncurses -L/usr/local/lib/tcl8.3 -Wl,--export-dynamic conftest.c -ltcl8.3 1>&5
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/../../../../i686-pc-cygwin/bin/ld: cannot find -ltcl8.3
collect2: ld returned 1 exit status
configure: failed program was:
#line 7978 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply. */
char Tcl_Init();

int main() {
Tcl_Init()
; return 0; }
configure:8016: checking for Tcl_Init in -ltcl83
configure:8033: gcc -o conftest -O2 -I/usr/include/ncurses -L/usr/local/lib/tcl8.3 -Wl,--export-dynamic conftest.c -ltcl83 1>&5
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/../../../../i686-pc-cygwin/bin/ld: cannot find -ltcl83
collect2: ld returned 1 exit status
configure: failed program was:
#line 8022 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply. */
char Tcl_Init();

int main() {
Tcl_Init()
; return 0; }
configure:8052: checking for Tcl_Init in -ltcl83
configure:8069: gcc -o conftest -O2 -I/usr/include/ncurses -L/usr/local/lib/tcl8.3 -Wl,--export-dynamic conftest.c -ltcl83 1>&5
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/../../../../i686-pc-cygwin/bin/ld: cannot find -ltcl83
collect2: ld returned 1 exit status
configure: failed program was:
#line 8058 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply. */
char Tcl_Init();

int main() {
Tcl_Init()
; return 0; }

==== 3/3/2004 NVWISH2.2 error message ====

Error in startup script: integer value too large to represent
   while executing
"expr int([lindex $range 0])"
   (procedure "mkcutplanePanel" line 55)
   invoked from within

Hmm. That's exactly the same error which Scott reported yesterday:

  http://intevation.de/rt/webrt?serial_num=2349

That was with 5.0.3 on Linux, so this may not actually be a Cygwin
issue. He reported that it only occurred when using a specific map for
the colours. Try different options, e.g. "nviz -q".

It works! I was launching with "nviz -q", which generated the above error, howerver "nviz map_name" opened Nviz in the twm windows manager. In the "rootless" mode the Nviz control panel exhibits some problems.

Thanks Glynn!

--
Richard Greenwood
www.greenwoodmap.com

Richard Greenwood wrote:

> I need to see the case (assuming that their is one) which fails with a
> different error. On any given system, four of the six attempts will
> normally fail with a "cannot find" error.
>
> The Tcl checks test for -ltcl, -ltcl8.3 and -ltcl83 (for the last two,
> the exact version number is taken from <tcl.h>), both with and without
> $DLLIB (which is set to the library which provides dlsym).
>
> Depending upon what your Tcl library is actually called, two of the
> three pairs will fail (if it's called libtcl8.3, the -ltcl and -ltcl83
> pairs will fail; the -ltcl8.3 pair would be the interesting one).

Below are the config.log results for all six tests. I should note that I
and using the switch:
    --with-tcltk-libs=/usr/local/lib/tcl8.3

Which is almost certainly wrong; configure finds none of -ltcl,
-ltcl8.3 or -ltcl83 in that directory.

/usr/local/lib/tcl8.3 is probably the directory which contains the
Tcl code, with the actual library in /usr/local/lib. In which case, it
should be:

  --with-tcltk-libs=/usr/local/lib

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

Glynn Clements wrote:

I should note that I and using the switch:
   --with-tcltk-libs=/usr/local/lib/tcl8.3

Which is almost certainly wrong; configure finds none of -ltcl,
-ltcl8.3 or -ltcl83 in that directory.

/usr/local/lib/tcl8.3 is probably the directory which contains the
Tcl code, with the actual library in /usr/local/lib. In which case, it
should be:

  --with-tcltk-libs=/usr/local/lib

Glynn,

As always, you are quite correct! I use a shell script to set my configure options and move the script forward between versions. I don't know when or why I set /usr/local/lib/tcl8.3, but it stopped working as of the grass53_exp_2004_01_10 snapshot. Which is probably a good thing as it was probably never correct in the first place.

Thanks Glynn.
Regards,
Rich

--
Richard Greenwood
www.greenwoodmap.com

On Sat, Mar 06, 2004 at 07:20:07PM +0000, Glynn Clements wrote:

Richard Greenwood wrote:

[...]

> ==== 3/3/2004 NVWISH2.2 error message ====
>
> Error in startup script: integer value too large to represent
> while executing
> "expr int([lindex $range 0])"
> (procedure "mkcutplanePanel" line 55)
> invoked from within

This suggests that GS_get_zrange_nz() is returning garbage, possibly
because it can't find a surface.

src/libes/ogsf/GS2.c

void GS_get_zrange_nz(float *min, float *max)
{
[...]
return;
}

Shouldn't it be
int GS_get_zrange_nz(float *min, float *max)
?

On the other hand in NVIZ there are no if statements
so maybe a test is needed there.

?
Markus

Markus Neteler wrote:

> > ==== 3/3/2004 NVWISH2.2 error message ====
> >
> > Error in startup script: integer value too large to represent
> > while executing
> > "expr int([lindex $range 0])"
> > (procedure "mkcutplanePanel" line 55)
> > invoked from within
>
> This suggests that GS_get_zrange_nz() is returning garbage, possibly
> because it can't find a surface.

src/libes/ogsf/GS2.c

void GS_get_zrange_nz(float *min, float *max)
{
[...]
return;
}

The problem is that it isn't guaranteed to write anything to *min and
*max. If they point to uninitialised variables on entry, they may
still be uninitialised upon return.

Shouldn't it be
int GS_get_zrange_nz(float *min, float *max)
?

That would only help if the caller bothers to check the return value.

On the other hand in NVIZ there are no if statements
so maybe a test is needed there.

?

There seem to be three alternative approaches:

1. Leave GS_get_zrange_nz() alone, and have the caller initialise the
variables to suitable defaults. Either GS_get_zrange_nz() will
overwrite them with other (valid) values, or they will remain
unchanged.

2. Change GS_get_zrange_nz() to write hardcoded defaults in the event
that it doesn't find a surface.

3. Change GS_get_zrange_nz() to return a status code, and change the
callers to handle failure.

Also, 3 could co-exist with either 1 or 2.

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