opengrads-devel — OpenGrADS development issues, with focus on interfaces and extensions

[Opengrads-devel] Failed to compile grads-2.0.2.oga.2 with supplibs-2.3.1 on cygwin

[Qian H. <yor...@gm...>]

Hi guys,
I was trying to compile grads-2.0.2.oga.2 on cygwin.

uname -a gets:
CYGWIN_NT-6.1-WOW yorua007-PC 2.1.0(0.287/5/3) 2015-07-14 21:26 i686 Cygwin

First I tried to using the pre-compiled supplibs-2.3.1, but get the
following errors:

g++  -g -O2  -lm -o libgrads.dll -shared  grads.o gxsubs.o gxmeta.o
gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o gafunc.o
gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o gabufrtbl.o gxX.o
gxdxwd.o galloc.o gagui.o gsgui.o dodstn.o gaddes.o gaio.o gacfg.o gauser.o
gasdf.o gatxt.o gaudx.o -L../../supplibs/lib   -lrpclib -lX11
../../supplibs/lib/libreadline.a ../../supplibs/lib/libncurses.a
 ../../supplibs/lib/libgd.a ../../supplibs/lib/libpng.a
../../supplibs/lib/libz.a ../../supplibs/lib/libjpeg.a
../../supplibs/lib/libgrib2c.a ../../supplibs/lib/libjasper.a
../../supplibs/lib/libpng.a ../../supplibs/lib/libz.a
../../supplibs/lib/libmfhdf.a ../../supplibs/lib/libdf.a
../../supplibs/lib/libudunits.a ../../supplibs/lib/libsz.a
../../supplibs/lib/libjpeg.a ../../supplibs/lib/libz.a
../../supplibs/lib/libhdf5.a ../../supplibs/lib/libsz.a
../../supplibs/lib/libjpeg.a ../../supplibs/lib/libz.a
../../supplibs/lib/libudunits.a ../../supplibs/lib/libnetcdf.a
../../supplibs/lib/libhdf5_hl.a ../../supplibs/lib/libhdf5.a
../../supplibs/lib/libz.a ../../supplibs/lib/libsz.a
../../supplibs/lib/libcurl.a -lSM -lICE  ../../supplibs/lib/libsx.a -lXext
-lXaw -lXpm -lXmu -lXt -lXdmcp -lXrender -lX11 ../../supplibs/lib/libtiff.a
../../supplibs/lib/libgeotiff.a ../../supplibs/lib/libshp.a
../../supplibs/lib/libgadap.a ../../supplibs/lib/libdapclient.a
../../supplibs/lib/libdap.a ../../supplibs/lib/libcurl.a
../../supplibs/lib/libxml2.a ../../supplibs/lib/libz.a -lpthread -lm -liconv
../../supplibs/lib/libmfhdf.a(putget.o):putget.c:(.text+0x3f)：对‘xdr_opaque’未定义的引用
../../supplibs/lib/libmfhdf.a(putget.o):putget.c:(.text+0xdf)：对‘xdr_opaque’未定义的引用
../../supplibs/lib/libmfhdf.a(putget.o):putget.c:(.text+0x2d1)：对‘xdr_opaque’未定义的引用
../../supplibs/lib/libmfhdf.a(putget.o):putget.c:(.text+0x3af)：对‘xdr_opaque’未定义的引用
../../supplibs/lib/libmfhdf.a(putget.o):putget.c:(.text+0x470)：对‘xdr_double’未定义的引用
../../supplibs/lib/libmfhdf.a(putget.o):putget.c:(.text+0x4a1)：对‘xdr_float’未定义的引用
../../supplibs/lib/libmfhdf.a(putget.o):putget.c:(.text+0x4b0)：对‘xdr_long’未定义的引用
../../supplibs/lib/libmfhdf.a(putget.o):putget.c:(.text+0x579)：对‘xdr_opaque’未定义的引用
../../supplibs/lib/libmfhdf.a(putget.o):putget.c:(.text+0x618)：对‘xdr_double’未定义的引用
../../supplibs/lib/libmfhdf.a(putget.o):putget.c:(.text+0x628)：对‘xdr_float’未定义的引用
../../supplibs/lib/libmfhdf.a(putget.o):putget.c:(.text+0x638)：对‘xdr_long’未定义的引用
../../supplibs/lib/libmfhdf.a(sharray.o):sharray.c:(.text+0x78)：对‘xdr_opaque’未定义的引用
../../supplibs/lib/libmfhdf.a(string.o):string.c:(.text+0x323)：对‘xdr_u_long’未定义的引用
../../supplibs/lib/libmfhdf.a(string.o):string.c:(.text+0x33e)：对‘xdr_opaque’未定义的引用
../../supplibs/lib/libmfhdf.a(string.o):string.c:(.text+0x354)：对‘xdr_u_long’未定义的引用
../../supplibs/lib/libmfhdf.a(string.o):string.c:(.text+0x3fc)：对‘xdr_opaque’未定义的引用
../../supplibs/lib/libmfhdf.a(string.o):string.c:(.text+0x42b)：对‘xdr_u_long’未定义的引用
../../supplibs/lib/libmfhdf.a(var.o):var.c:(.text+0xcf8)：对‘xdr_enum’未定义的引用
../../supplibs/lib/libmfhdf.a(var.o):var.c:(.text+0xd0d)：对‘xdr_u_long’未定义的引用
../../supplibs/lib/libmfhdf.a(var.o):var.c:(.text+0xd3b)：对‘xdr_u_long’未定义的引用
../../supplibs/lib/libmfhdf.a(array.o):array.c:(.text+0xd83)：对‘xdr_enum’未定义的引用
../../supplibs/lib/libmfhdf.a(array.o):array.c:(.text+0xd93)：对‘xdr_u_long’未定义的引用
../../supplibs/lib/libmfhdf.a(array.o):array.c:(.text+0xdfe)：对‘xdr_enum’未定义的引用
../../supplibs/lib/libmfhdf.a(array.o):array.c:(.text+0xf22)：对‘xdr_double’未定义的引用
../../supplibs/lib/libmfhdf.a(array.o):array.c:(.text+0xf30)：对‘xdr_float’未定义的引用
../../supplibs/lib/libmfhdf.a(array.o):array.c:(.text+0xf3a)：对‘xdr_long’未定义的引用
../../supplibs/lib/libmfhdf.a(array.o):array.c:(.text+0xf81)：对‘xdr_opaque’未定义的引用
../../supplibs/lib/libmfhdf.a(cdf.o):cdf.c:(.text+0x4b)：对‘xdr_opaque’未定义的引用
../../supplibs/lib/libmfhdf.a(cdf.o):cdf.c:(.text+0x30c8)：对‘xdr_u_long’未定义的引用
../../supplibs/lib/libmfhdf.a(cdf.o):cdf.c:(.text+0x31a7)：对‘xdr_u_long’未定义的引用
../../supplibs/lib/libmfhdf.a(cdf.o):cdf.c:(.text+0x3c88)：对‘xdr_double’未定义的引用
../../supplibs/lib/libmfhdf.a(cdf.o):cdf.c:(.text+0x3d00)：对‘xdr_long’未定义的引用
../../supplibs/lib/libmfhdf.a(cdf.o):cdf.c:(.text+0x3d0e)：对‘xdr_float’未定义的引用
../../supplibs/lib/libmfhdf.a(cdf.o):cdf.c:(.text+0x30ff)：对‘xdr_u_long’未定义的引用
../../supplibs/lib/libmfhdf.a(dim.o):dim.c:(.text+0x7ad)：对‘xdr_long’未定义的引用
../../supplibs/lib/libmfhdf.a(iarray.o):iarray.c:(.text+0x117)：对‘xdr_u_long’未定义的引用
../../supplibs/lib/libmfhdf.a(iarray.o):iarray.c:(.text+0x148)：对‘xdr_int’未定义的引用
../../supplibs/lib/libmfhdf.a(iarray.o):iarray.c:(.text+0x16c)：对‘xdr_u_long’未定义的引用
../../supplibs/lib/libmfhdf.a(iarray.o):iarray.c:(.text+0x20b)：对‘xdr_int’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller7get_strERSs’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:145：对‘xdr_string’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller10get_vectorEPPcRjiRNS_6VectorE’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:185：对‘xdr_array’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller10get_vectorEPPcRjRNS_6VectorE’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:175：对‘xdr_bytes’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller7get_intERi’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:168：对‘xdr_int’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller10get_uint32ERj’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:136：对‘xdr_u_int’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller10get_uint16ERt’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:129：对‘xdr_u_short’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller11get_float64ERd’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:122：对‘xdr_double’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller11get_float32ERf’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:115：对‘xdr_float’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller9get_int32ERi’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:108：对‘xdr_int’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller9get_int16ERs’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:101：对‘xdr_short’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller8get_byteERh’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:94：对‘xdr_char’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRFileUnMarshaller.o)：在函数‘ZN6libdap19XDRFileUnMarshaller10get_opaqueEPcj’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRFileUnMarshaller.cc:162：对‘xdr_opaque’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRUtils.o)：在函数‘Z12new_xdrstdioP9__sFILE646xdr_op’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRUtils.cc:52：对‘xdrstdio_create’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRUtils.o)：在函数‘Z12set_xdrstdioP3XDRP9__sFILE646xdr_op’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRUtils.cc:60：对‘xdrstdio_create’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRUtils.o)：在函数‘xdr_str’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRUtils.cc:100：对‘xdr_string’未定义的引用
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRUtils.cc:106：对‘xdr_string’未定义的引用
../../supplibs/lib/libdap.a(libdap_la-XDRUtils.o)：在函数‘ZN6libdap8XDRUtils9xdr_coderERKNS_4TypeE’中：
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRUtils.cc:148：对‘xdr_short’未定义的引用
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRUtils.cc:151：对‘xdr_u_short’未定义的引用
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRUtils.cc:154：对‘xdr_int’未定义的引用
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRUtils.cc:157：对‘xdr_u_int’未定义的引用
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRUtils.cc:160：对‘xdr_float’未定义的引用
/home/dasilva/src/supplibs-2.3.1/src/dap/XDRUtils.cc:163：对‘xdr_double’未定义的引用
collect2: 错误：ld 返回 1
GNUmakefile:56: recipe for target 'libgrads.dll' failed
make[2]: *** [libgrads.dll] Error 1
make[2]: Leaving directory '/home/yorua007/software/grads-2.0.2.oga.2/src'
Makefile:590: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/yorua007/software/grads-2.0.2.oga.2/src'
Makefile:410: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

After searching the web, I installed the sunrpc from the supplib-2.3.1
source tarball, but got the same error messages.
Then I tried to compile supplib-2.3.1 from the source, but failed to
compile the cairo library, and the error message is:

      if (!isxdigit(font->eexec_segment[i]))
      ^
  CC     cairo-type3-glyph-surface.lo
  CC     cairo-pdf-operators.lo
  CC     cairo-pdf-shading.lo
  CC     cairo-deflate-stream.lo
  CC     cairo-xlib-display.lo
In file included from cairo-xlib-private.h:41:0,
                 from cairo-xlib-display.c:40:
cairo-xlib-xrender-private.h:102:16: error: redefinition of 'struct
_XLinearGradient'
 typedef struct _XLinearGradient {
                ^
In file included from cairo-xlib-xrender.h:45:0,
                 from cairo-xlib-xrender-private.h:53,
                 from cairo-xlib-private.h:41,
                 from cairo-xlib-display.c:40:
/home/yorua007/software/supplibs-2.3.1/i686-pc-cygwin/include/X11/extensions/Xrender.h:186:16:
note: originally defined here
 typedef struct _XLinearGradient {
                ^
In file included from cairo-xlib-private.h:41:0,
                 from cairo-xlib-display.c:40:
cairo-xlib-xrender-private.h:105:3: error: conflicting types for
'XLinearGradient'
 } XLinearGradient;
   ^
In file included from cairo-xlib-xrender.h:45:0,
                 from cairo-xlib-xrender-private.h:53,
                 from cairo-xlib-private.h:41,
                 from cairo-xlib-display.c:40:
/home/yorua007/software/supplibs-2.3.1/i686-pc-cygwin/include/X11/extensions/Xrender.h:189:3:
note: previous declaration of 'XLinearGradient' was here
 } XLinearGradient;
   ^
In file included from cairo-xlib-private.h:41:0,
                 from cairo-xlib-display.c:40:
cairo-xlib-xrender-private.h:111:16: error: redefinition of 'struct
_XCircle'
 typedef struct _XCircle {
                ^
In file included from cairo-xlib-xrender.h:45:0,
                 from cairo-xlib-xrender-private.h:53,
                 from cairo-xlib-private.h:41,
                 from cairo-xlib-display.c:40:
/home/yorua007/software/supplibs-2.3.1/i686-pc-cygwin/include/X11/extensions/Xrender.h:146:16:
note: originally defined here
 typedef struct _XCircle {
                ^
In file included from cairo-xlib-private.h:41:0,
                 from cairo-xlib-display.c:40:
cairo-xlib-xrender-private.h:115:3: error: conflicting types for 'XCircle'
 } XCircle;
   ^
In file included from cairo-xlib-xrender.h:45:0,
                 from cairo-xlib-xrender-private.h:53,
                 from cairo-xlib-private.h:41,
                 from cairo-xlib-display.c:40:
/home/yorua007/software/supplibs-2.3.1/i686-pc-cygwin/include/X11/extensions/Xrender.h:150:3:
note: previous declaration of 'XCircle' was here
 } XCircle;
   ^
In file included from cairo-xlib-private.h:41:0,
                 from cairo-xlib-display.c:40:
cairo-xlib-xrender-private.h:116:16: error: redefinition of 'struct
_XRadialGradient'
 typedef struct _XRadialGradient {
                ^
In file included from cairo-xlib-xrender.h:45:0,
                 from cairo-xlib-xrender-private.h:53,
                 from cairo-xlib-private.h:41,
                 from cairo-xlib-display.c:40:
/home/yorua007/software/supplibs-2.3.1/i686-pc-cygwin/include/X11/extensions/Xrender.h:191:16:
note: originally defined here
 typedef struct _XRadialGradient {
                ^
In file included from cairo-xlib-private.h:41:0,
                 from cairo-xlib-display.c:40:
cairo-xlib-xrender-private.h:119:3: error: conflicting types for
'XRadialGradient'
 } XRadialGradient;
   ^
In file included from cairo-xlib-xrender.h:45:0,
                 from cairo-xlib-xrender-private.h:53,
                 from cairo-xlib-private.h:41,
                 from cairo-xlib-display.c:40:
/home/yorua007/software/supplibs-2.3.1/i686-pc-cygwin/include/X11/extensions/Xrender.h:194:3:
note: previous declaration of 'XRadialGradient' was here
 } XRadialGradient;
   ^
In file included from cairo-xlib-private.h:41:0,
                 from cairo-xlib-display.c:40:
cairo-xlib-xrender-private.h:125:16: error: redefinition of 'struct
_XConicalGradient'
 typedef struct _XConicalGradient {
                ^
In file included from cairo-xlib-xrender.h:45:0,
                 from cairo-xlib-xrender-private.h:53,
                 from cairo-xlib-private.h:41,
                 from cairo-xlib-display.c:40:
/home/yorua007/software/supplibs-2.3.1/i686-pc-cygwin/include/X11/extensions/Xrender.h:196:16:
note: originally defined here
 typedef struct _XConicalGradient {
                ^
In file included from cairo-xlib-private.h:41:0,
                 from cairo-xlib-display.c:40:
cairo-xlib-xrender-private.h:128:3: error: conflicting types for
'XConicalGradient'
 } XConicalGradient;
   ^
In file included from cairo-xlib-xrender.h:45:0,
                 from cairo-xlib-xrender-private.h:53,
                 from cairo-xlib-private.h:41,
                 from cairo-xlib-display.c:40:
/home/yorua007/software/supplibs-2.3.1/i686-pc-cygwin/include/X11/extensions/Xrender.h:199:3:
note: previous declaration of 'XConicalGradient' was here
 } XConicalGradient;
   ^
Makefile:2090: recipe for target 'cairo-xlib-display.lo' failed
make[4]: *** [cairo-xlib-display.lo] Error 1
make[4]: Leaving directory
'/home/yorua007/software/supplibs-2.3.1/src/cairo/src'
Makefile:2582: recipe for target 'install' failed
make[3]: *** [install] Error 2
make[3]: Leaving directory
'/home/yorua007/software/supplibs-2.3.1/src/cairo/src'
Makefile:632: recipe for target 'install-recursive' failed
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory
'/home/yorua007/software/supplibs-2.3.1/src/cairo'
Makefile:1051: recipe for target 'install' failed
make[1]: *** [install] Error 2
make[1]: Leaving directory
'/home/yorua007/software/supplibs-2.3.1/src/cairo'
GNUmakefile:605: recipe for target 'cairo.install' failed
make: *** [cairo.install] Error 2

I tried to fix this but failed. I see that the cairo is built with the
pre-compiled supplib-2.3.1, so the cairo is able to be successfully
compiled on the cygwin platform.Are there any suggestions to help out?

Thanks!

-- 
Hao Qian
Key Laboratory of Ocean Circulation and Waves (KLOCAW)
Institute of Oceanology, Chinese Academy of Sciences
No.7 Nanhai Road, Qingdao 266071, P.R.China
Phone: +86-18753220258

Re: [Opengrads-devel] opengrads webpage not working?

[Arlindo da S. <da...@al...>]

On Tue, Nov 11, 2014 at 1:01 PM, suvarchal kumar <suv...@gm...>
wrote:

> HI there, i have been trying last days to see cookbooks section in
> opengrads webpage, it seems something is broken on the server? many other
> links also dont work. or is it only me.
>
>
​We will take a look at it. It could be related to a recent PHP upgrade by
the ISP.

    Arlindo

-- 
Arlindo da Silva
*da...@al... <da...@al...>*

[Opengrads-devel] opengrads webpage not working?

[suvarchal k. <suv...@gm...>]

HI there, i have been trying last days to see cookbooks section in
opengrads webpage, it seems something is broken on the server? many other
links also dont work. or is it only me.

Cheers,
Suvarchal

Re: [Opengrads-devel] make

[Simone E. <sim...@gm...>]

Hi Arlindo.

Thanks for the quick response.

1) Are you building the opengrads sources or the vanilla grads from cola?
I used grads from cola, tried several versions (2.1, 2.0, 1.9, etc)

2) Did you build your own supplibs or are using the open grads pre-compiled
ones?
I build supplibs (http://www.iges.org/grads/gadoc/supplibs.html). Since
readline until pkgconfig.

3) What is your platform? I mean "uname -a", "ldd --version"
Linux pc4 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux

ldd (Ubuntu EGLIBC 2.19-0ubuntu6.3) 2.19

regards
Simone








2014-09-01 23:12 GMT-03:00 Arlindo da Silva <da...@al...>:

> Simone,
>
>    A couple of questions,
>
> 1) Are you building the opengrads sources or the vanilla grads from cola?
>
> 2) Did you build your own supplibs or are using the open grads
> pre-compiled ones?
>
> 3) What is your platform? I mean "uname -a", "ldd --version"
>
>    Arlindo
>
>
> On Fri, Aug 29, 2014 at 4:26 PM, Simone ETFerraz <sim...@gm...>
> wrote:
>
>> I configure grads-2.0.2 with:
>>
>> ./configure CC=gcc CXX=g++  LIBS='-fPIC' SUPPLIBS='/usr/local/supplibs'
>> --with-readline --with-sdf --with-geotiff='/usr/local/supplibs/src/geotiff'
>> --with-geotiff-include='/usr/local/supplibs/include/geotiff'
>>  --with-geotiff-libdir='/usr/local/supplibs/lib'
>> --with-hdf4='/usr/local/supplibs/src/hdf'
>> --with-hdf4-include='/usr/local/supplibs/include/hdf'
>>  --with-hdf4-libdir='/usr/local/supplibs/lib'
>> --with-hdf5='/usr/local/supplibs/src/hdf5'
>> --with-hdf5-include='/usr/local/supplibs/include/hdf5'
>> --with-hdf5-libdir='/usr/local/supplibs/lib'
>> --with-netcdf='/usr/local/supplibs/src/netcdf'
>> --with-netcdf-include='/usr/local/supplibs/include/netcdf'
>>  --with-netcdf-libdir='/usr/local/supplibs/lib'
>>  --prefix='/usr/local/supplibs/src/grads'
>>
>> it's, ok, but with make:
>>
>> /usr/local/supplibs/lib/libnetcdf.a(liboc_la-occontent.o): In function
>> `memset':
>> /usr/include/x86_64-linux-gnu/bits/string3.h:81: warning: memset used
>> with constant zero length parameter; this could be due to transposed
>> parameters
>> /usr/bin/ld: /usr/local/supplibs/lib/libhdf5.a(H5PL.o): undefined
>> reference to symbol 'dlclose@@GLIBC_2.2.5'
>> //lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from
>> command line
>> collect2: error: ld returned 1 exit status
>> make[2]: *** [grads] Error 1
>> make[2]: Leaving directory `/usr/local/supplibs/src/grads-2.0.2/src'
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory `/usr/local/supplibs/src/grads-2.0.2/src'
>> make: *** [all-recursive] Error 1
>>
>>
>> what's problem?
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds.  Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> Opengrads-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>>
>>
>
>
> --
> Arlindo da Silva
> *da...@al... <da...@al...>*
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>


-- 
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Simone Erotildes Teleginski Ferraz
# Centro de Ciências Naturais e Exatas
# Departamento de Física
# Universidade Federal de Santa Maria - RS
# 55 55 33012032
# Av. Roraima 1000 - Camobi
# 97105900 - Santa Maria - Rio Grande do Sul
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

Re: [Opengrads-devel] make

[Arlindo da S. <da...@al...>]

Simone,

   A couple of questions,

1) Are you building the opengrads sources or the vanilla grads from cola?

2) Did you build your own supplibs or are using the open grads pre-compiled
ones?

3) What is your platform? I mean "uname -a", "ldd --version"

   Arlindo


On Fri, Aug 29, 2014 at 4:26 PM, Simone ETFerraz <sim...@gm...>
wrote:

> I configure grads-2.0.2 with:
>
> ./configure CC=gcc CXX=g++  LIBS='-fPIC' SUPPLIBS='/usr/local/supplibs'
> --with-readline --with-sdf --with-geotiff='/usr/local/supplibs/src/geotiff'
> --with-geotiff-include='/usr/local/supplibs/include/geotiff'
>  --with-geotiff-libdir='/usr/local/supplibs/lib'
> --with-hdf4='/usr/local/supplibs/src/hdf'
> --with-hdf4-include='/usr/local/supplibs/include/hdf'
>  --with-hdf4-libdir='/usr/local/supplibs/lib'
> --with-hdf5='/usr/local/supplibs/src/hdf5'
> --with-hdf5-include='/usr/local/supplibs/include/hdf5'
> --with-hdf5-libdir='/usr/local/supplibs/lib'
> --with-netcdf='/usr/local/supplibs/src/netcdf'
> --with-netcdf-include='/usr/local/supplibs/include/netcdf'
>  --with-netcdf-libdir='/usr/local/supplibs/lib'
>  --prefix='/usr/local/supplibs/src/grads'
>
> it's, ok, but with make:
>
> /usr/local/supplibs/lib/libnetcdf.a(liboc_la-occontent.o): In function
> `memset':
> /usr/include/x86_64-linux-gnu/bits/string3.h:81: warning: memset used with
> constant zero length parameter; this could be due to transposed parameters
> /usr/bin/ld: /usr/local/supplibs/lib/libhdf5.a(H5PL.o): undefined
> reference to symbol 'dlclose@@GLIBC_2.2.5'
> //lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from
> command line
> collect2: error: ld returned 1 exit status
> make[2]: *** [grads] Error 1
> make[2]: Leaving directory `/usr/local/supplibs/src/grads-2.0.2/src'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/usr/local/supplibs/src/grads-2.0.2/src'
> make: *** [all-recursive] Error 1
>
>
> what's problem?
>
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>


-- 
Arlindo da Silva
*da...@al... <da...@al...>*

[Opengrads-devel] make

[Simone E. <sim...@gm...>]

I configure grads-2.0.2 with:

./configure CC=gcc CXX=g++  LIBS='-fPIC' SUPPLIBS='/usr/local/supplibs'
--with-readline --with-sdf --with-geotiff='/usr/local/supplibs/src/geotiff'
--with-geotiff-include='/usr/local/supplibs/include/geotiff'
 --with-geotiff-libdir='/usr/local/supplibs/lib'
--with-hdf4='/usr/local/supplibs/src/hdf'
--with-hdf4-include='/usr/local/supplibs/include/hdf'
 --with-hdf4-libdir='/usr/local/supplibs/lib'
--with-hdf5='/usr/local/supplibs/src/hdf5'
--with-hdf5-include='/usr/local/supplibs/include/hdf5'
--with-hdf5-libdir='/usr/local/supplibs/lib'
--with-netcdf='/usr/local/supplibs/src/netcdf'
--with-netcdf-include='/usr/local/supplibs/include/netcdf'
 --with-netcdf-libdir='/usr/local/supplibs/lib'
 --prefix='/usr/local/supplibs/src/grads'

it's, ok, but with make:

/usr/local/supplibs/lib/libnetcdf.a(liboc_la-occontent.o): In function
`memset':
/usr/include/x86_64-linux-gnu/bits/string3.h:81: warning: memset used with
constant zero length parameter; this could be due to transposed parameters
/usr/bin/ld: /usr/local/supplibs/lib/libhdf5.a(H5PL.o): undefined reference
to symbol 'dlclose@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from
command line
collect2: error: ld returned 1 exit status
make[2]: *** [grads] Error 1
make[2]: Leaving directory `/usr/local/supplibs/src/grads-2.0.2/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/supplibs/src/grads-2.0.2/src'
make: *** [all-recursive] Error 1


what's problem?

Re: [Opengrads-devel] Shared Library Error Prevents OpenGrADS 2.0.2 From Starting

[Arlindo da S. <da...@al...>]

On Wed, Jul 2, 2014 at 10:48 AM, Devin Boyer <db...@ws...> wrote:

> Hi Arlindo,
>
> Thanks for the reply. Unfortunately, just adding "libstdc++.so.6" didn't
> work (it eliminated those errors, but the ones pointing to libc.so.6
> remain). If I only add the "libc.so.6" library to gex and don't include
> "libstdc++.so.6", I get the errors referring to that library (like "/usr/lib/libstdc++.so.6:
> version `GLIBCXX_3.4.11' not found") only, with no complaints on behalf of
> libc.so.6. Adding both nets you the "unexpected PLT reloc" error for
> "libc.so.6".
>
>
GrADS binaries are very portable across Linux distributions provided that
the libc is compatible. In the end, changes in libc is what get us. That is
the reason why I had started labeling the binaries with the libc version.


> Those details are probably (hopefully) water under the bridge if I am able
> to build from source. Unfortunately I see this morning the OpenGrADS wiki
> is down. Are there instructions elsewhere, by chance?
>
>
The wiki is temporarily down due to a PHP upgrade, we hope to have it fixed
soon.

As for the build, download the source tarball from

   https://sourceforge.net/projects/opengrads/files/grads2/2.0.2.oga.2

(or the latest 2.1.a2.oga.1 if you wish.) Untar and read the included
"BUILD" file.  As for dependencies, I'd start with the latest pre-compiled
supplibs 2.3.1,

     https://sourceforge.net/projects/opengrads/files/supplibs/2.3.1/

and see if you can get away with it (there is a good chance that will
work). Otherwise, build the supplibs yourself from the source tarball in
this directory (see file INSTALL).

     Good Luck,

        Arlindo




> Thanks again,
> Devin
>
>
> On Wed, Jul 2, 2014 at 10:29 AM, Arlindo da Silva <da...@al...>
> wrote:
>
>> On Tue, Jul 1, 2014 at 12:02 PM, Devin Boyer <db...@ws...> wrote:
>>
>>> Hi there,
>>>
>>> I'm attempting to install OpenGrads 2.0.2.oga.2 on our CentOS 5 machine
>>> and am running into some difficulty. I downloaded
>>> the grads-2.0.2.oga.2-bundle-i686-pc-linux-gnu.tar.gz package and untarred
>>> it. When I first run "grads" from this, I get 7 errors, 3 that version of
>>> GLIBCX aren't found (in  /usr/lib/libstdc++.so.6) and 4 that versions of
>>> GLIBC aren't found (in /lib/libc.so.6). (I can provide the exact error
>>> output if that is helpful.)
>>>
>>> To remedy, I tried to copy those libraries from those included in the
>>> libs directory to the gex directory, as suggested in the documentation.
>>>
>>
>> As mentioned in the documentation, add only one library at a time. If it
>> complained about "libstdc++.so.6" then add this one and see what happens.
>> Do not not add "libc.so.6" unless you have a reason to do so.
>>
>>
>>> After doing that, I now get this error:
>>>
>>> /opt/opengrads2.0.2/Linux/Versions/2.0.2.oga.2/i686/grads: error while
>>> loading shared libraries:
>>> /opt/opengrads2.0.2/Linux/Versions/2.0.2.oga.2/i686/gex/libc.so.6:
>>> unexpected PLT reloc type 0x2a
>>>
>>>
>> Try removing libc.so.6 from gex/ and see what happens (but keep
>> libstc++.so.6). I know it is counter intuitive.
>>
>>
>>>
>>> Interestingly enough, if I download the previous GrADS release
>>> (2.0.1.oga.1), everything works fine if I simply just extract contents of
>>> the tarball.
>>>
>>
>> Release 2.0.1 was built in 2011 and it is possible that I has running
>> CentOS 5 back then. My i686 build machine is a recent Ubuntu release.
>>
>>
>>> This happens with both the oga.1 and oga.2 releases of version 2.0.2. I
>>> did notice that there's a bit of a difference in filenames between 2.0.1
>>> and 2.0.2 - could this be part of the difference?
>>>
>>> grads-2.0.1.oga.1-bundle-i686-glibc2.5-linux-gnu.tar.gz
>>> -versus-
>>> grads-2.0.2.oga.2-bundle-i686-pc-linux-gnu.tar.gz
>>>
>>
>>
>>  I was including the libc version  by hand just for reference and I
>> forgot to do it this time; this should not be an issue.
>>
>>
>>>
>>> Does this seem to be some sort of issue with the distribution or does it
>>> seem more like a problem on my end?
>>>
>>>
>> Try removing libc.so.6 from gex/ and let me know what it happens. If it
>> still does not work we will need to perform a build on your machine. Please
>> post you reply on gradsusr in order to provide a searcheable reference for
>> this particular issue.
>>
>>
>>      Arlindo
>>
>>
>> --
>> Arlindo da Silva
>> *da...@al... <da...@al...>*
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community
>> Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Opengrads-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>


-- 
Arlindo da Silva
*da...@al... <da...@al...>*

Re: [Opengrads-devel] Shared Library Error Prevents OpenGrADS 2.0.2 From Starting

[Devin B. <db...@ws...>]

Hi Arlindo,

Thanks for the reply. Unfortunately, just adding "libstdc++.so.6" didn't
work (it eliminated those errors, but the ones pointing to libc.so.6
remain). If I only add the "libc.so.6" library to gex and don't include
"libstdc++.so.6", I get the errors referring to that library (like
"/usr/lib/libstdc++.so.6:
version `GLIBCXX_3.4.11' not found") only, with no complaints on behalf of
libc.so.6. Adding both nets you the "unexpected PLT reloc" error for
"libc.so.6".

Those details are probably (hopefully) water under the bridge if I am able
to build from source. Unfortunately I see this morning the OpenGrADS wiki
is down. Are there instructions elsewhere, by chance?

Thanks again,
Devin


On Wed, Jul 2, 2014 at 10:29 AM, Arlindo da Silva <da...@al...>
wrote:

> On Tue, Jul 1, 2014 at 12:02 PM, Devin Boyer <db...@ws...> wrote:
>
>> Hi there,
>>
>> I'm attempting to install OpenGrads 2.0.2.oga.2 on our CentOS 5 machine
>> and am running into some difficulty. I downloaded
>> the grads-2.0.2.oga.2-bundle-i686-pc-linux-gnu.tar.gz package and untarred
>> it. When I first run "grads" from this, I get 7 errors, 3 that version of
>> GLIBCX aren't found (in  /usr/lib/libstdc++.so.6) and 4 that versions of
>> GLIBC aren't found (in /lib/libc.so.6). (I can provide the exact error
>> output if that is helpful.)
>>
>> To remedy, I tried to copy those libraries from those included in the
>> libs directory to the gex directory, as suggested in the documentation.
>>
>
> As mentioned in the documentation, add only one library at a time. If it
> complained about "libstdc++.so.6" then add this one and see what happens.
> Do not not add "libc.so.6" unless you have a reason to do so.
>
>
>> After doing that, I now get this error:
>>
>> /opt/opengrads2.0.2/Linux/Versions/2.0.2.oga.2/i686/grads: error while
>> loading shared libraries:
>> /opt/opengrads2.0.2/Linux/Versions/2.0.2.oga.2/i686/gex/libc.so.6:
>> unexpected PLT reloc type 0x2a
>>
>>
> Try removing libc.so.6 from gex/ and see what happens (but keep
> libstc++.so.6). I know it is counter intuitive.
>
>
>>
>> Interestingly enough, if I download the previous GrADS release
>> (2.0.1.oga.1), everything works fine if I simply just extract contents of
>> the tarball.
>>
>
> Release 2.0.1 was built in 2011 and it is possible that I has running
> CentOS 5 back then. My i686 build machine is a recent Ubuntu release.
>
>
>> This happens with both the oga.1 and oga.2 releases of version 2.0.2. I
>> did notice that there's a bit of a difference in filenames between 2.0.1
>> and 2.0.2 - could this be part of the difference?
>>
>> grads-2.0.1.oga.1-bundle-i686-glibc2.5-linux-gnu.tar.gz
>> -versus-
>> grads-2.0.2.oga.2-bundle-i686-pc-linux-gnu.tar.gz
>>
>
>
> I was including the libc version  by hand just for reference and I forgot
> to do it this time; this should not be an issue.
>
>
>>
>> Does this seem to be some sort of issue with the distribution or does it
>> seem more like a problem on my end?
>>
>>
> Try removing libc.so.6 from gex/ and let me know what it happens. If it
> still does not work we will need to perform a build on your machine. Please
> post you reply on gradsusr in order to provide a searcheable reference for
> this particular issue.
>
>
>      Arlindo
>
>
> --
> Arlindo da Silva
> *da...@al... <da...@al...>*
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>

Re: [Opengrads-devel] Shared Library Error Prevents OpenGrADS 2.0.2 From Starting

[Arlindo da S. <da...@al...>]

On Tue, Jul 1, 2014 at 12:02 PM, Devin Boyer <db...@ws...> wrote:

> Hi there,
>
> I'm attempting to install OpenGrads 2.0.2.oga.2 on our CentOS 5 machine
> and am running into some difficulty. I downloaded
> the grads-2.0.2.oga.2-bundle-i686-pc-linux-gnu.tar.gz package and untarred
> it. When I first run "grads" from this, I get 7 errors, 3 that version of
> GLIBCX aren't found (in  /usr/lib/libstdc++.so.6) and 4 that versions of
> GLIBC aren't found (in /lib/libc.so.6). (I can provide the exact error
> output if that is helpful.)
>
> To remedy, I tried to copy those libraries from those included in the libs
> directory to the gex directory, as suggested in the documentation.
>

As mentioned in the documentation, add only one library at a time. If it
complained about "libstdc++.so.6" then add this one and see what happens.
Do not not add "libc.so.6" unless you have a reason to do so.


> After doing that, I now get this error:
>
> /opt/opengrads2.0.2/Linux/Versions/2.0.2.oga.2/i686/grads: error while
> loading shared libraries:
> /opt/opengrads2.0.2/Linux/Versions/2.0.2.oga.2/i686/gex/libc.so.6:
> unexpected PLT reloc type 0x2a
>
>
Try removing libc.so.6 from gex/ and see what happens (but keep
libstc++.so.6). I know it is counter intuitive.


>
> Interestingly enough, if I download the previous GrADS release
> (2.0.1.oga.1), everything works fine if I simply just extract contents of
> the tarball.
>

Release 2.0.1 was built in 2011 and it is possible that I has running
CentOS 5 back then. My i686 build machine is a recent Ubuntu release.


> This happens with both the oga.1 and oga.2 releases of version 2.0.2. I
> did notice that there's a bit of a difference in filenames between 2.0.1
> and 2.0.2 - could this be part of the difference?
>
> grads-2.0.1.oga.1-bundle-i686-glibc2.5-linux-gnu.tar.gz
> -versus-
> grads-2.0.2.oga.2-bundle-i686-pc-linux-gnu.tar.gz
>


I was including the libc version  by hand just for reference and I forgot
to do it this time; this should not be an issue.


>
> Does this seem to be some sort of issue with the distribution or does it
> seem more like a problem on my end?
>
>
Try removing libc.so.6 from gex/ and let me know what it happens. If it
still does not work we will need to perform a build on your machine. Please
post you reply on gradsusr in order to provide a searcheable reference for
this particular issue.


     Arlindo


-- 
Arlindo da Silva
*da...@al... <da...@al...>*

Re: [Opengrads-devel] Shared Library Error Prevents OpenGrADS 2.0.2 From Starting

[Mike F. <mfi...@gm...>]

hi Devin,

my guess is a conflict with your distro...have you tried building from source?  CentOS5 is a bit dated...  sorry I can't be more helpful

best /R Mike

On 2014-07-01, 16:02 , Devin Boyer wrote:
> Hi there,
>
> I'm attempting to install OpenGrads 2.0.2.oga.2 on our CentOS 5 machine and am running into some difficulty. I downloaded 
> the grads-2.0.2.oga.2-bundle-i686-pc-linux-gnu.tar.gz package and untarred it. When I first run "grads" from this, I get 7 errors, 3 that version of 
> GLIBCX aren't found (in  /usr/lib/libstdc++.so.6) and 4 that versions of GLIBC aren't found (in /lib/libc.so.6). (I can provide the exact error 
> output if that is helpful.)
>
> To remedy, I tried to copy those libraries from those included in the libs directory to the gex directory, as suggested in the documentation. After 
> doing that, I now get this error:
>
> /opt/opengrads2.0.2/Linux/Versions/2.0.2.oga.2/i686/grads: error while loading shared libraries: 
> /opt/opengrads2.0.2/Linux/Versions/2.0.2.oga.2/i686/gex/libc.so.6: unexpected PLT reloc type 0x2a
>
>
> Interestingly enough, if I download the previous GrADS release (2.0.1.oga.1), everything works fine if I simply just extract contents of the 
> tarball. This happens with both the oga.1 and oga.2 releases of version 2.0.2. I did notice that there's a bit of a difference in filenames between 
> 2.0.1 and 2.0.2 - could this be part of the difference?
>
> grads-2.0.1.oga.1-bundle-i686-glibc2.5-linux-gnu.tar.gz
> -versus-
> grads-2.0.2.oga.2-bundle-i686-pc-linux-gnu.tar.gz
>
> Does this seem to be some sort of issue with the distribution or does it seem more like a problem on my end?
>
> Thanks!
>
> Sincerely,
> Devin Boyer
> Software Engineer, WSI Corp.
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
>
>
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel

[Opengrads-devel] Shared Library Error Prevents OpenGrADS 2.0.2 From Starting

[Devin B. <db...@ws...>]

Hi there,

I'm attempting to install OpenGrads 2.0.2.oga.2 on our CentOS 5 machine and
am running into some difficulty. I downloaded
the grads-2.0.2.oga.2-bundle-i686-pc-linux-gnu.tar.gz package and untarred
it. When I first run "grads" from this, I get 7 errors, 3 that version of
GLIBCX aren't found (in  /usr/lib/libstdc++.so.6) and 4 that versions of
GLIBC aren't found (in /lib/libc.so.6). (I can provide the exact error
output if that is helpful.)

To remedy, I tried to copy those libraries from those included in the libs
directory to the gex directory, as suggested in the documentation. After
doing that, I now get this error:

/opt/opengrads2.0.2/Linux/Versions/2.0.2.oga.2/i686/grads: error while
loading shared libraries:
/opt/opengrads2.0.2/Linux/Versions/2.0.2.oga.2/i686/gex/libc.so.6:
unexpected PLT reloc type 0x2a


Interestingly enough, if I download the previous GrADS release
(2.0.1.oga.1), everything works fine if I simply just extract contents of
the tarball. This happens with both the oga.1 and oga.2 releases of version
2.0.2. I did notice that there's a bit of a difference in filenames between
2.0.1 and 2.0.2 - could this be part of the difference?

grads-2.0.1.oga.1-bundle-i686-glibc2.5-linux-gnu.tar.gz
-versus-
grads-2.0.2.oga.2-bundle-i686-pc-linux-gnu.tar.gz

Does this seem to be some sort of issue with the distribution or does it
seem more like a problem on my end?

Thanks!

Sincerely,
Devin Boyer
Software Engineer, WSI Corp.

Re: [Opengrads-devel] What about grads 2.1

[Wang J. <da...@gm...>]

That’s great! Thanks!
在 2014年5月27日，11:53，Arlindo da Silva <da...@AL...> 写道：

> Although there will be no opengrads release for 2.1.a1, we will release opengrads 2.1.a2 as soon as cola releases their 2.1.a2. We already have a working prototype, including new extensions. It shouldn't be too long.

Re: [Opengrads-devel] What about grads 2.1

[Arlindo da S. <da...@al...>]

On Friday, May 23, 2014, Wang Jun <da...@gm...> wrote:

> the newest version of GrADS now is 2.1.a1. And it has great improvement
> especially in graphics quality as http://www.iges.org/grads/ChangeLog says.
> In my opinion the improvement is historical.
>
> Please upgrade opengrads to 2.1 so we can benefit from the GrADS
> improvement. Thanks.
>

Although there will be no opengrads release for 2.1.a1, we will release
opengrads 2.1.a2 as soon as cola releases their 2.1.a2. We already have a
working prototype, including new extensions. It shouldn't be too long.

  Arlindo


-- 
Arlindo da Silva
*da...@al... <da...@al...>*

[Opengrads-devel] What about grads 2.1

[Wang J. <da...@gm...>]

the newest version of GrADS now is 2.1.a1. And it has great improvement especially in graphics quality as http://www.iges.org/grads/ChangeLog says. In my opinion the improvement is historical. 

Please upgrade opengrads to 2.1 so we can benefit from the GrADS improvement. Thanks.

Re: [Opengrads-devel] Importing data from Python -> GrADS

[Arlindo da S. <da...@al...>]

On Sat, Nov 16, 2013 at 7:04 AM, Joao Rafael Dias Pinto <
joa...@ia...> wrote:

> Dear all,
>
> I am using pygrads to make the "comunication" between python and GrADS but
> I am having problem with the function import.
>


What kind of problems?


> I have geopotential filtered data (ntimes, nlatitudes, nlongitudes) that I
> computed by using a python code, but I am having problems to import these
> data to GrADS.
>

I believe you can only import 2D fields (ntimes=1), sorry.

    Arlindo


> Since
> I am not totally familiar with python, I dont understand very much how to
> specify correctly the parameters of imp. function. It is said that:
>
> #........................................................................
>
>     def imp ( self, name, Field ):
>         """
>         Sends a GrADS Field containing a NumPy array and associated
>         grid information to GrADS, defining it in GrADS as *name*.
>         Notice that *Field* can be an instance of the GaField
>         class or a tuple with the (Array,Grid) components.
>
>
> I believe my problems are the Field and name parameters. Does anyone know
> to use this function?
>
> Thanks in advance,
>
> João
>
> Department of Atmospheric Sciences,
> University of São Paulo - Brazil
>
>
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>


-- 
Arlindo da Silva
*da...@al... <da...@al...>*

[Opengrads-devel] Importing data from Python -> GrADS

[Joao R. D. P. <joa...@ia...>]

Dear all, 

I am using pygrads to make the "comunication" between python and GrADS but I am having problem with the function import. 
I have geopotential filtered data (ntimes, nlatitudes, nlongitudes) that I computed by using a python code, but I am having problems to import these data to GrADS. Since 
I am not totally familiar with python, I dont understand very much how to specify correctly the parameters of imp. function. It is said that: 

#........................................................................ 

def imp ( self, name, Field ): 
""" 
Sends a GrADS Field containing a NumPy array and associated 
grid information to GrADS, defining it in GrADS as *name*. 
Notice that *Field* can be an instance of the GaField 
class or a tuple with the (Array,Grid) components. 


I believe my problems are the Field and name parameters. Does anyone know to use this function? 

Thanks in advance, 

João 

Department of Atmospheric Sciences, 
University of São Paulo - Brazil 

[Opengrads-devel] pygrads: GrADS.imp problem with non latlon grids

[Lorenzo M. <lor...@un...>]

Hi all,
I have exactly the same problem: trying to export data from grads to python, from a grib file with a
non latlon grid, pygrads fails with the following error:


grads.gacore.GrADSError: 'invalid exchange metadata (idim,jdim)=(0,77724220109037511232075876794368)
- make sure <ugrd10m> is valid and that lon/lat is varying.'


Trying to debug the code I find exactly the same results as Davide.

To make things clearer, I submit a sample grib to verify the problem. To see it enter the folder where
you placed the file example.grb2.ctl and use the following commands:

>>> from grads import *
>>> g = GrADS()
>>> g.open("example.grb2.ctl")
>>> data = g.imp("ugrd10m")

You will see the error message. The example file contains a lambert conformal grid, but it seems to me that the problem
arises with every non latlon grid.

Thank you for the help!

Cheers,

Lorenzo




> Dears,
> We noticed some errors using pygrads with ctl files including pdef
> directives. Our grid is rotated, we used either pdef bilin or pdef
> rotllr, but errors on grid.meta in ganum._exp2d() are the same
> (exception raised on line 234 of ganum.py)

> It might be that there are some problems in parsing the first 20 values
> from ipc_save, or are we doing anything wrong?

> Using debug at line 224:
         (Pdb) grid.meta
         array([  1.84689701e+25,   1.57883589e-19,   7.77242201e+31,
                  7.14408185e+31,   4.10594102e+04,   1.93472401e-19,
                  7.21432390e+22,   1.15785712e+27,   7.22507008e+28,
                  2.44565409e+20,   1.12586784e+24,   2.72450326e+20,
                 -2.86196307e-23,   9.03173995e-39,   0.00000000e+00,
                  5.83155401e-39,   6.17844824e-39,   6.16194655e-39,
                  5.83155401e-39,  -1.19687500e+01], dtype=float32)
         

> configuration
> grads:   v2.0.1.oga.1
> python:  2.7.3
> pygrads: 1.1.b5
> numpy:   1.6.2

> thank you very much for your help
> Davide

[Opengrads-devel] pygrads: galab sampleXY problems

[Lorenzo M. <lor...@un...>]

Hi all,
I'm not sure this is the right place to post about pygrads.

I found two problems using galab method sampleXY.

The first problem is that invoking it, I get the error
"NameError: global name 'lon' is not defined"

The second problem is that parameter dh is completely ignored.

I fixed the method in order to make it function for me, and I'm sending 
you the patched version.

I hope it can be useful.

Lorenzo

#########################################
#########################################
#########################################
     def sampleXY ( self, expr, lons, lats, levs=None, dh=None, **kwopts):
         if len(lons.shape)!=1 or len(lats.shape)!=1:
             raise GrADSError, "lons, lats, time must be 1D arrays"


         # Retrieve dimension environment
         # ------------------------------
######### I ADDED THE IF  ###############
         if not dh:
           dh = self.query("dims", Quiet=True)
###########################################

         # Loop over time, performing interpolation
         # ----------------------------------------
         g = GaGrid("sampleXY")
         g.time = []
         V  = ma.masked_array(zeros((len(lons),dh.nt,dh.nz)),dtype=float32)
         for t in dh.ti:
             n = t - dh.ti[0]
             self.cmd('set t %d'%t, Quiet=True)
######### I ADDED dh=dh  #############
             v, g.lev = self._interpXY ( expr, lons, lats,
                                            levs=levs, dh=dh,
                                            **kwopts)
###########################################
             if len(v.shape)==1:
                 V[:,n,0] = v
             else:
                 V[:,n,:] = v
             qh =self.query("time",Quiet=True)
             g.time.append(qh.t1)

         g.dims = ['obs',]
         if dh.nt>1:
             g.dims.append('time')
         if dh.nz>1:
             g.dims.append('lev')

######### I GUESS THIS IS THE RIGHT ASSIGNMENT #############
         g.lon, g.lat = (lons, lats) # "obs" coordinates
###################################################
         g.tyme = array([gat2dt(t) for t in g.time])

#       Restore dimension environment
#       -----------------------------
         self.setdim(dh)
         V = V.squeeze()
         return GaField(V.data, name=expr, grid=g,
                        mask=V.mask, dtype=float32)
#   ..................................................................

#########################################
#########################################
#########################################

[Opengrads-devel] command line autocomplete

[Elbers, J. <Jan...@wu...>]

Hello,

Since I installed version 2.0.1 Win Superpack on a Windows 7 64bit PC the command line autocomplete does not work anymore. It used to work fine with version 2.0.a9 on a Windows XP machine. Anyone ideas on how to fix this?

Cheers,
Jan
Wageningen University and Research

Re: [Opengrads-devel] problem in new grads

[Brian D. <do...@co...>]

Arlindo, thanks for this info.  Your suggested approach looks very attractive... Brian

----- Original Message -----
From: "Arlindo da Silva" <arl...@na...>
To: "Jennifer Adams" <jm...@co...>
Cc: "Brian E. Doty" <do...@co...>, ope...@li...
Sent: Wednesday, December 28, 2011 9:18:54 PM
Subject: Re: problem in new grads

On Thu, Dec 22, 2011 at 3:47 PM, Jennifer Adams < jm...@co... > wrote: 





When evaluating the mathematical expression, there's a test to see if the denominator is close to zero with a precision of e-8. 


if (dequal(*val2,0.0,1e-08)==0) *uval2 = 0; 




This is very problematic and will create numerous problems when dealing with chemical constituents with very low concentrations (ppb). Also, GrADS is not very consistent at the moment with zero tests in other functions 






ga-> d log(1e-12) 


Result value = -27.631 


ga-> d log(0) 


Warning from LOG: Data has 1 values <= zero 


These were set to the undefined value 


Result value = -9.99e+08 





In addition, this "check for zero" really defeats the purpose of IEEE representation of floats/doubles. You want to check whether the mantissa is zero, regardless of exponent. That aside, with the inclusion of the the mask in GrADS 2.0, a much better solution would be to make use of the IEEE float point exception handling feature available with modern compilers (autoconf can check for that). See the attached code snippet for sample usage of the isnan(), isinf(), isnormal() functions. For example, nowadays 


1.0/0.0 evaluates to Inf 
sqrt(-1.) evaluates to NaN 
exp(VERY_LARGE_NUMBER) evaluates to Inf 


A faster and more robust approach would be to eliminate these zero tests from the code and examine the validity of the result with built in functions isnan() and isinf(), setting the "mask" when such an IEEE exception is returned. Right now GrADS does not handle overflows, try this: 






ga-> d exp(1.e249) 


Result value = inf 



I believe that you would want to return UNDEFs in this case as well. 


BTW, the isnormal() built in function can be used to check for zeros, see attached. 


Arlindo 

Re: [Opengrads-devel] problem in new grads

[Arlindo da S. <arl...@na...>]

On Thu, Dec 22, 2011 at 3:47 PM, Jennifer Adams <jm...@co...> wrote:

> When evaluating the mathematical expression, there's a test to see if the
> denominator is close to zero with a precision of e-8.
>
>  if (dequal(*val2,0.0,1e-08)==0) *uval2 = 0;
>
>
This is very problematic and will create numerous problems when dealing
with chemical constituents with very low concentrations (ppb). Also, GrADS
is not very consistent at the moment with zero tests in other functions

ga-> d log(1e-12)
Result value = -27.631
ga-> d log(0)
Warning from LOG:  Data has 1 values <= zero
                   These were set to the undefined value
Result value = -9.99e+08



In addition, this "check for zero"  really defeats the purpose of IEEE
representation of floats/doubles. You want to check whether the mantissa is
zero, regardless of exponent. That aside, with the inclusion of the the
mask in GrADS 2.0, a much better solution would be to make use of the IEEE
float point exception handling feature available with modern compilers
(autoconf can check for that).  See the attached code snippet for sample
usage of the isnan(), isinf(), isnormal() functions. For example, nowadays

1.0/0.0 evaluates to Inf
sqrt(-1.) evaluates to NaN
exp(VERY_LARGE_NUMBER) evaluates to Inf

A faster and more robust approach would be to eliminate these zero tests
from the code and examine the validity of the result with built in
functions isnan() and isinf(), setting the "mask" when such an IEEE
exception is returned. Right now GrADS does not handle overflows, try this:

ga-> d exp(1.e249)
Result value = inf


I believe that you would want to return UNDEFs in this case as well.

 BTW, the isnormal() built in function can be used to check for zeros, see
attached.

       Arlindo

Re: [Opengrads-devel] Dat File re-reads

[Love, M. G. C. C. 7. <gar...@nr...>]

Brian,

If I use the ‘reinit’ command will this force a re-read of the map files?

Happy Thanksgiving,
Gary

From: Brian Doty [mailto:do...@co...]
Sent: Thursday, October 13, 2011 7:56 AM
To: Love, Mr. Gary, Contractor, Code 7542
Cc: ope...@li...; Frost, Mr. Michael
Subject: Re: [Opengrads-devel] Dat File re-reads

Ok, not too hard, I've added some basic caching of the map file to
gxwmap.c.  The changes are all isolated to gxwmap.c for now.  I kinda
did this quick so I haven't done a whole lot of testing on it.  The
cache lasts for the entire grads session.  I don't think this hurts
performance any for those cases when grads is just being run to do one
plot.  This mod is applied to the gxwmap.c from the 2.0.0 code base --
but we will not include it in 2.0; it will be included in 2.1.  Right
now the CACHEMAX is set to 2MB which will cache lowres, mres, and
hires.  If you have your own map files that are larger, you may want
to increase the CACHEMAX value.  This will have no affect on shapefile
usage.

Gary, I'm not really sure this will help your situation; it will
depend on your system environment.  Arlindo's suggestion to set up
some system-wide solution like a ramdisk may be more along the lines
of what you need... Brian



On Oct 12, 2011, at 8:38 PM, Love, Mr. Gary, Contractor, Code 7542
wrote:

> Arlindo,
>
> We have some solid state disks that function as local disks because
> the global file systems running gpfs are too slow.  So our challenge
> is how to accomplish how to do the “shared memory” which we also
> thought of using.
>
> Do you know if anyone else has this problem and who could benefit
> from the solution?
>
> Thanks for your input.  I’ll ask for more when we get into the
> project.
>
> Gary
>
> From: Arlindo da Silva [mailto:da...@al...]
> Sent: Wednesday, October 12, 2011 4:41 PM
> To: ope...@li...<mailto:ope...@li...>
> Cc: Brian Doty; Frost, Mr. Michael
> Subject: Re: [Opengrads-devel] Dat File re-reads
>
> On Wed, Oct 12, 2011 at 3:16 PM, Love, Mr. Gary, Contractor, Code
> 7542 <gar...@nr...<mailto:gar...@nr...>> wrote:
> Hi Brian, Jennifer,
>
> We use GrADS extensively in a production mode and have found when
> profiling GrADS runs that 2/3 rds of the data reads are the
> coastlines and font files.  This may not sound like much, but at
> FNMOC when running 100's of charts for each of 32 multi-grid
> projects, the coastline and font reads amount to terabytes for each
> 12 hour set of runs.
>
> The re-reads occur for each and every display of a variable from the
> same file after it is opened.  We are going to try to store these
> files in memory after the first read.
>
> My first question is whether anyone else has looked at this and has
> a solution?  My next questions, do you have any ideas or guidance to
> help us do this?
>
> I know that GrADS was designed to operate well on small platforms
> with little memory, so our goal is to implement a memory caching
> capability that would be controlled by a 'set' command and would be
> moderated by the amount of memory available.
>
> As Brian mentions, the map and font database are relatively small.
> So, it would be very feasible to setup a ramdisk to hold these files
> which would probably give you a nice performance boost with
> virtually no programming involved. Depending on your system
> architecture, this ramdisk could effectively function as "shared
> memory" used by multiple cores. (Because grads is not thread safe,
> having an explicit memory buffer to hold this would require that
> each grads process duplicate the memory necessary to hold the maps/
> font databases.)  One hardware solution is to place grads and its
> data on a solid state disk, these are quite affordable these days.
>
>   Just my 2 lazy cents.
>
>        Arlindo
>
> --
> Arlindo da Silva
> da...@al...<mailto:da...@al...>

Re: [Opengrads-devel] Partial transparency (alpha channel)

[Jennifer A. <jm...@co...>]

Hi, Arlindo --

On Nov 20, 2011, at 5:32 PM, Arlindo da Silva wrote:

> Brian, Jennifer:
>
>    In GrADS 2.1, would you consider extending "set rgb" to accept an  
> extra "alpha" channel? Since, you now use cairo for rendering,  
> taking advantage of the channel is really trivial, you can take a  
> look at what we did in gxyat. Partial transparency is very useful to  
> create plots like this one: 153722. If you wish I can contribute a  
> reference implementation once the 2.1 sources are available.
Brian did some testing with partial transparency using gd, and found  
some subtleties that we need to think about. I have some stand-alone  
code to handle semi-transparency in cairo, but we haven't integrated  
anything into the GrADS code base yet. We are still working on the  
changes to the structure of the metafile buffer, then we will add the  
new features on top of those changes.

>
>    We could also have gxyat built in (gxyat is nothing more than  
> "gxpng" modified to use cairo).  Because gd is much faster than  
> cairo, there always will be a place for printim as we know it, don't  
> you think?
The rendering with X11 will remain an option, as well as speedy  
generation of image output with the gd library via printim. But we are  
no longer going to support any metafile translators, so that we have  
the freedom to change the metafile structure without having to worry  
about supporting all the external utilities too. The ability to write  
out the contents of the metafile buffer to a file will be removed, so  
gxps, gxeps, gxtran, gxyat, and gv32.exe will all die with version  
2.1. The creation of all vector graphics output formats will only be  
supported inside GrADS via cairo.

--Jennifer

[Opengrads-devel] Partial transparency (alpha channel)

[Arlindo da S. <da...@al...>]

Brian, Jennifer:

   In GrADS 2.1, would you consider extending "set rgb" to accept an extra
"alpha" channel? Since, you now use cairo for rendering, taking advantage
of the channel is really trivial, you can take a look at what we did in
gxyat<http://opengrads.cvs.sourceforge.net/viewvc/opengrads/contrib/extensions/gxyat/gxyat.c?revision=1.9&view=markup>.
Partial transparency is very useful to create plots like this one:
153722<http://sourceforge.net/projects/opengrads/screenshots/153722>.
If you wish I can contribute a reference implementation once the 2.1
sources are available.

   We could also have gxyat built in (gxyat is nothing more than "gxpng"
modified to use cairo).  Because gd is much faster than cairo, there always
will be a place for printim as we know it, don't you think?

    Arlindo

---------- Forwarded message ----------
From: Arlindo da Silva <da...@al...>
Date: Sun, Nov 20, 2011 at 5:12 PM
Subject: Re: [gradsusr] Two gxout shaded value in one plot
To: GrADS Users Forum <gra...@gr...>


On Sat, Nov 19, 2011 at 1:12 PM, Joe Moore <jo...@wx...> wrote:

> Hello!
>
> Can you provide the code you are trying to use? I'm having trouble
> understanding exactly what you mean.
>
> Overlaying two shaded displays will result in the first being covered by
> the second unless you specify to only shade certain values of the second.
> While it is possible to set a shaded value to transparent using the latest
> GrADS version (use set gxout shade2 and set the color to -1 to be
> transparent), it is not possible (not my knowledge) to do any kind of
> partial transparency.
>
>
Yes, youn can, with the the "set_rgba" command in opengrads. It works just
like "set rgb" but in addition to the red/green/blue values you specify an
"alpha" value that controls the opacity of that color, see below. The
caveat is that you do not see the transparency on the screen, only when you
create the output with gxyat (png, svg, pdf or ps). (When Grads 2.1 is
released I believe we will be able to extend this feature to screen output
as well.)

    Arlindo


*NAME*
     set_rgba - define color including alpha channel

*SYNOPSIS*
     set_rgba color red green blue alpha [mask]

*DESCRIPTION*
     This User Defined Command (UDC) defines *color* given its
     RGB triplet along with its *alpha* channel.

     color   integer in the range [16-255]
     red,
     green,
     blue    integers in the range [0-255]
     alpha   float, with alpha ranging from 0.0 (fully transparent)
             to 1.0 (fully opaque).

    The optional parameter *mask* determines whether the color below
    it is visible or not.

    mask=0  --- if alpha<1, *color* will be semi-transparent and the
                colors below it will be visible (default)
    mask=1  --- if alpha<1, *color* will be semi-transparent but the
                colors below it will *not* be visible

*EXAMPLE*
    In order to emulate the -t option in printim

       ga-> set rgb 60 125 125 125
       ga-> printim img.png -t 60

       Specify alpha=0 and mask=1

       ga-> set_rgba 60 125 125 125 0 1
       ga-> gxyat img.png

-Joe
>
>
> On Sat, Nov 19, 2011 at 3:21 AM, Cuba <jak...@o2...> wrote:
>
>> Hellow Gradsuser,
>> I try make two gxout shaded value in one plot, but this not go.
>> I know as make shaded value and countur in one plot, but in this time i
>> needs two shaded value.
>> Please for help.
>>
>>
>> _______________________________________________
>> gradsusr mailing list
>> gra...@gr...
>> http://gradsusr.org/mailman/listinfo/gradsusr
>>
>
>
> _______________________________________________
> gradsusr mailing list
> gra...@gr...
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>


-- 
Arlindo da Silva
da...@al...



-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] GrADS binary for ia64

[Denis B. <for...@gm...>]

<div>Dear Experts,<br /> To my pleasure recently there was a new version GrADS 2.0.1 .<br /> For Linux there are two packages: i686 and x86-64.<br /> But at our institute use processors Itanium (ia64) and I used the version grads-2.0.a5.oga.5-bundle-ia64-unknown-linux-gnu.tar.gz two year.<br /> Unfortunately now there is no package for architecture ia64.<br /><br /> I have a question: it is planned to make a package of GrADS for ia64?<br /> Or it is necessary to use emulation?<br /><br /> Thank you!!<br /> --Denis<br /><br /> ===========================================================<br /> Denis Blinov<br /> Hydrometcentre of Russia http://www.meteoinfo.ru<br /> 11-13, B.Predtechensky st, Moscow, 123242<br /> E-mail: den...@me...</div>