20010209: 20010209: gempak decoders in gempak.56a

Ruth,

Apparently there is an incompatibility in the libraries.

I compiled the solaris binaries here using WS6, eg the
/opt/SUNWspro/lib/libsunmath.so.1 here is a link to:
   ../WS6/lib/libsunmath.so.1

Steve Chiswell
Unidata User Support




>From: Ruth Platner <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200102091853.f19IrlL08018

>Unidata Support wrote:
>
>> Ruth,
>>
>> Do you have any dc log file output from these decoders in data/gempak/logs?
>>
>
>No there is nothing being written to the log files.
>
>>
>> If you don't have any decode logs, then you might check to make sure that
>> the decoders themselves are viewable and executable by the ldm (just incase
>> the umask was set when they were installed) as well as the paths to
>> the  /ljuka/gemadm/gempak/bin/sol directory.
>
>These are executable
>-rwxr-xr-x   1 gemadm   staff     328800 Dec 15 13:44 dcgrib2
>-rwxr-xr-x   1 gemadm   staff     343472 Dec 15 13:42 dcmetr
>
>> The otherthing to check is to make sure that the ldm process can invoke
>> the programs, try typing "ldd  /ljuka/gemadm/gempak/bin/sol/dcgrib2" for
>> example from the ldm account. Its possible that the decoder is looking for
>> runtime shared libraries (like /opt/SUNWspro/lib/....) and not finding them.
>> The ldd command will show you what libraries are trying to be resolved, and
>> if any aren't being found.
>
>aspre ldm 69% ldd  /ljuka/gemadm/gempak/bin/sol/dcgrib2
>        libm.so.1 =>     /burga/bopt/SUNWspro/lib/libm.so.1
>        libsocket.so.1 =>        /usr/lib/libsocket.so.1
>        libnsl.so.1 =>   /usr/lib/libnsl.so.1
>        libF77.so.4 =>   /burga/bopt/SUNWspro/lib/libF77.so.4
>        libM77.so.2 =>   /burga/bopt/SUNWspro/lib/libM77.so.2
>        libsunmath.so.1 =>       /burga/bopt/SUNWspro/lib/libsunmath.so.1
>        libc.so.1 =>     /usr/lib/libc.so.1
>        libdl.so.1 =>    /usr/lib/libdl.so.1
>        libmp.so.2 =>    /usr/lib/libmp.so.2
>
>This looks good to me, but ...
>
>If I type dcgrib, I get the usual output about usage:
>Usage: dcgrib [options] output_file
>Options:
>        -h           Print the help file, then exit the program
>        -v           Verbose, report decoding steps
>
>But If I type "dcgrib2", I get the following:
>ld.so.1: dcgrib2: fatal: relocation error: file dcgrib2: symbol __s_rsFe_pv:
>referenced symbol not found
>Killed
>
>I switched the order of my LD_LIBRARY_PATH for user ldm to put
>/ljuka/gemadm/gempak/lib/sol first and that has stopped this problem. The gemp
> ak
>libraries were last before. So the problem was with the libraries, but the out
> put
>of the "ldd" command wasn't telling me that was it?
>
>Here's the output of "ldd" now:
>aspre  ldm !%  ldd  /ljuka/gemadm/gempak/bin/sol/dcgrib2
>        libm.so.1 =>     /ljuka/gemadm/gempak/lib/sol/libm.so.1
>        libsocket.so.1 =>        /usr/lib/libsocket.so.1
>        libnsl.so.1 =>   /usr/lib/libnsl.so.1
>        libF77.so.4 =>   /ljuka/gemadm/gempak/lib/sol/libF77.so.4
>        libM77.so.2 =>   /ljuka/gemadm/gempak/lib/sol/libM77.so.2
>        libsunmath.so.1 =>       /ljuka/gemadm/gempak/lib/sol/libsunmath.so.1
>        libc.so.1 =>     /usr/lib/libc.so.1
>        libdl.so.1 =>    /usr/lib/libdl.so.1
>        libmp.so.2 =>    /usr/lib/libmp.so.2
>
>
>Now that my library path is fixed, the gempak files are being created and ther
> e
>don't seem to be any more errors.
>
>Thanks for your help,
>
>Ruth
>
>
>>
>>
>> Steve Chiswell
>>
>> >From: Ruth Platner <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200102091618.f19GIhL01549
>>
>> >Hi,
>> >
>> >I'm having trouble with the new ldm decoders that are part of gempak
>> >version 56a. The NWX entries in pqact.conf are fine, but all of the
>> >gempak decoder entries are failing. I've now turned off all gempak
>> >decoders except for the following two pqact.conf entries:
>> >
>> >HRS     ^H.[I-P]... KWB. ([0-3][0-9])([0-2][0-9]).*
>> >        PIPE    /ljuka/gemadm/gempak/bin/sol/dcgrib2 -d
>> >data/gempak/logs/dcgrib.log
>> >                -e GEMTBL=/ljuka/gemadm/gempak/gempak/tables
>> >                data/gempak/hds/YYYYMMDDHH_thin.gem
>> >
>> >
>> >
>> >DDS|IDS ^S[AP].* .... ([0-3][0-9])([0-2][0-9])
>> >        PIPE    /ljuka/gemadm/gempak/bin/sol/dcmetr -b 9 -m 72 -s
>> >sfmetar_sa.tbl
>> >        -d data/gempak/logs/dcmetr.log
>> >        -e GEMTBL=/ljuka/gemadm/gempak/gempak/tables
>> >        data/gempak/surface/YYYYMMDD_sao.gem
>> >
>> >Here's some of the errors from the log file
>> >Feb 09 15:51:14 aspre pqact[4561]: pbuf_flush (4) write: Broken pipe
>> >Feb 09 15:51:14 aspre pqact[4561]: pipe_dbufput:
>> >/ljuka/gemadm/gempak/bin/sol/d
>> >cgrib2-ddata/gempak/logs/dcgrib.log-eGEMTBL=/ljuka/g
>> >Feb 09 15:51:14 aspre pqact[4561]: pipe_prodput: trying again
>> >Feb 09 15:51:14 aspre pqact[4561]: child 23835 terminated by signal 9
>> >
>> >Feb 09 15:37:34 aspre pqact[4561]: pbuf_flush (4) write: Broken pipe
>> >Feb 09 15:37:34 aspre pqact[4561]: pipe_dbufput:
>> >/ljuka/gemadm/gempak/bin/sol/dc
>> >metr-b9-m72-ssfmetar_sa.tbl-ddata/gempak/logs/dcmetr
>> >Feb 09 15:37:34 aspre pqact[4561]: pipe_prodput: trying again
>> >Feb 09 15:37:34 aspre pqact[4561]: child 22425 terminated by signal 9
>> >
>> >These data directories exist and have the same ownership as ldm. There
>> >are no existing files in the hds or surface directories either.
>> >
>> >aspre gempak 704% ls -al
>> >total 30
>> >drwxr-xr-x  13 ldm      staff        512 Feb  2 10:56 .
>> >drwxr-xr-x   8 ldm      staff        512 Jan 31 01:07 ..
>> >drwxr-xr-x   2 ldm      staff        512 Sep  1 13:56 acars
>> >drwxr-xr-x   2 ldm      staff       2560 Jan 31 18:00 hds
>> >drwxr-xr-x   2 ldm      staff        512 Jan 30 17:59 logs
>> >drwxr-xr-x   2 ldm      staff        512 Feb  2 10:56 model
>> >drwxr-xr-x   2 ldm      staff        512 Jan 31 18:00 mos
>> >drwxr-xr-x   2 ldm      staff        512 Sep  7  1999 nldn
>> >drwxr-xr-x  17 ldm      staff        512 Jan 30 19:26 nwx
>> >drwxr-xr-x   2 ldm      staff        512 Sep  1 13:56 profiler
>> >drwxr-xr-x   6 ldm      staff        512 Sep  1 13:55 storm
>> >drwxr-xr-x   2 ldm      staff       1024 Feb  7 18:00 surface
>> >drwxr-xr-x   2 ldm      staff        512 Feb  5 18:00 upperair
>> >aspre gempak 705% pwd
>> >/home/ldm/data/gempak
>> >
>> >aspre gempak 706% /usr/ucb/ps -auxww | grep ldm
>> >ldm       4561  0.9 10.310203225464 ?        S 02:00:05  3:38 pqact
>> >ldm      22521  0.6  0.8 2576 1824 ?        S 10:38:06  0:34
>> >/usr/local/ldm/decoders/bin/gribtonc -q lin
>> >decoders/etc/part.avn-1.25x1.25.cdl
>> >data/GRIB/2001020912_avn-1.25x1.25.nc
>> >ldm       4560  0.3 10.110136824888 ?        S 02:00:05  1:25 pqbinstats
>> >
>> >ldm       4562  0.3 12.010149629624 ?        S 02:00:05  1:36 rpc.ldmd
>> >-q /usr/local/ldm/data/ldm.pq /usr/local/ldm/etc/ldmd.conf
>> >
>> >I'm running ldm-5.1.2 on a Sparc Ultra 10 with SunOS 5.7.
>> >
>> >The usual reason for those signal 9 errors is nonexistent data
>> >directories or ownership problems with the data directories, but I don't
>> >see that here.
>> >
>> >Thanks for your help,
>> >
>> >Ruth
>> >
>>
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>