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.
>To: address@hidden >From: Jason Thaxter <address@hidden> >Subject: Re: 20030715: perl interface problem, plus ncdump oddity >Organization: GoMOOS >Keywords: 200309161520.h8GFKSLd005087, perl, ncdump, FreBSD gcc Hi Jason, > I've found two odd problems with NetCDF tools recently. I suspect they are > related to compiler and perl versions, but I don't really know. > > 1) ---------------------------------------------------- > > The Perl interface issue involves values retrieved by NetCDF::recget. The > variable is a scalar of type BYTE. Perl always thinks it has a zero (0), even > though the value (according to ncdump and according to the people who put the > value there) is a 1 or even a 3. When I treat the value as a string, I get > funny control characters - Perl should normally have either an empty string or > a '0' (zero) depending on the context. This appears to be related to a > similar problem I once had - a value that actually was zero cause a coredump > when I tried operating on it, which I worked around with something like: > perl -v -9 > > This problem can be observed on netcdf-perl-1.2.2, on > FreeBSD-4.8+gcc-2.95.4+perl-5.8.0, as well as on > FreeBSD-5.1+gcc-3.2.2+perl-5.6.1. > > The older problem with zeroes was on netcdf-perl-1.2.1, perl version 5.6.0, > Redhat Linux 7.1 and 7.2. If you could provide us with a small example that demonstrates the problem so we could reproduce it here, we might be able to diagnose and fix it. > 2) ---------------------------------------------------- > > The second problem I've had is with incorrect values returned by ncdump: > time for consecutive hours expressed in Julian days is coming out as: > time = 2452830.85694444, 14695227408.0627, 775946.000980392, > with the FreeBSD ports version of netcdf 3.5.0. Another compile comes out > with correct versions: > time = 2452830.85694444, 2452830.89861111, 2452830.94027778 > > The differences are: > Incorrect: gcc-2.95.4 (compiled under freebsd 4.7, linked to libc.so.4) > Correct: gcc-3.2.2 (compiled under freebsd-5.1, linked to libc.so.5) > > Any insight onto these would be a big help. The issue with the Perl > interface is more pressing to me, though probably more complicated. If you built from source, did you run "make test" from the src/ directory after building the library with the package built with gcc-2.95.4, and did all the tests pass? If there were no problems with the "make test", then we would be very interested in a way to reproduce the problem here. Again a small test case that allowed us to reproduce the problem would be ideal. --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://my.unidata.ucar.edu