[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030418: ldm build with weather's gdbm

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20030418: ldm build with weather's gdbm
  • Date: Fri, 18 Apr 2003 10:45:56 -0600
Neil,

> To: address@hidden
> From: "Neil R. Smith" <address@hidden>
> Subject: ldm build with weather's gdbm
> Organization: TAMU

The above message contained the following:

> I think my gdbm metar files aren't being created according to compatability 
> with our weather (v4.10) program. 
> 
> How do I ensure that the ldm (6.0.10) build will be using the gdbm library 
> from Neilly's weather program on my FreeBSD (4.7) box?
> 
> Problem evidence:
> Running the metar app. in a working linux binary of weather on the freebsd 
> box 
> with gdbm enabled (gdbm = true in weather.init):
> > weather -c metar cll l
> gdbm fatal: read error.
> Whereas with the weather program set to read flat asci file for the metar 
> data 
> (gdbm = false in weather.init):
> > weather -c metar cll l
> KCLL 172253Z 24004KT 9SM CLR 28/17 A2991 RMK AO2 SLP123 T02780167=
> KCLL 172253Z 24004KT 9SM CLR 28/17 A2991=
> So the binary runs and it can read the ingested flat asci metar data but not 
> the gdbm output files. I discovered this, actually, when we started to see 
> this weather/metar problem on our IRIX box with weather 4.10 that used to 
> read the gdbm files just fine when the gdbm files were being generated by the 
> old 5.2 ldm run on our retired IRIX box. Now weather on said IRIX box core 
> dumps on metar read attempts. weather doesn't core dump on this freebsd box 
> but gives the above error.
> 
> What I did:
> 1. did make in weather distr. src/gdbm directory, resulting in no errors and 
> a 
> libgdbm.a (can't get a full build of the weather program to fly yet; if you 
> know of someone who's done this, would appreciate the info.)
> 2. copied this libgdbm.a to a place for it to be found:
>      /unidata/ldm/weather.bsd/lib
> 3. assured the gdbm.h from the weather distr. can be found in:
>     /unidata/ldm/weather.bsd/include
> 4. setenv GDBMLIB "-L/unidata/ldm/weather.bsd/lib -lgdbm"
>     setenv CPPFLAGS -I/unidata/ldm/weather.bsd/include
> 5.
> > cd $LDMHOME
> > make distclean
> > ./configure >&! configure.log
> > make >&! make.log
> > make install >&! install.log
> # make install_setuids 
> 6. redo local mods to ldmadmin
> 7. remove all exiting files from the output dir specified in the
>     DBFILE action in pqsurf.conf
> 8. start ldm and wait for DBFILE's to be created
> 9. run a working linux binary of weather on the box
> 10. get the above-mentioned errors.
> 
> Notice: in the ldm src dir from the above rebuild :
> > grep gdbm *.log
> config.log:configure:2093: checking for gdbm.h
> configure.log:checking for gdbm.h... yes
> make.log:c89 -o pqact -O action.o filel.o palt.o pbuf.o pqact.o ../libldm.a 
> -lm -L/unidata/ldm/weather.bsd/lib -lgdbm
> 
> Does the last line indicate which gdbm was actually used? Or did the build 
> actually use the freebsd distro lib: /usr/local/lib/libgdbm.a ?

The last "make.log" line above indicates that the pqact program should
use the GDBM library /unidata/ldm/weather.bsd/libgdbm.a -- assuming that
that library contains the appropriate functions.  You should test that
assumption via the command

    nm -g /unidata/ldm/weather.bsd/libgdbm.a

or something similar.

I'm afraid that I don't see anything wrong in your build of the LDM.

> Thanks, -Neil
> -- 
> Neil R. Smith Comp.Sys.Mngr.
> address@hidden        
> Dept. Atmospheric Sciences, Texas A&M University

Regards,
Steve Emmerson