Hi Rob: It is quite possible that there is a typemap or other problem in
the PDL::NetCDF library that fails when sizeof(long) is 4 and
sizeof(size_t) is 8. I don't have access to a platform with that
combination, and I did have to add special logic to get PDL::NetCDF to
work with 64-bit compilers.
My guess would be that around line 1657 of netcdf.pd (shown below) the
test for $Config{'longsize'} shows 4, so both $st and $ct are packed as
4-byte vectors, whereas they should be packed as 8 byte vectors. If you
can find a way of testing for this using Config.pm, I'd be happy to add a
patch.
Regards,
Doug
#------------------------------------------------------------------------------------------------------
# Add these statements for machines w/64 bit longs
if ($Config{'longsize'} == 8) { pp_addpm ('
my $st = pack ("Q*", @$start);
my $ct = pack ("Q*", @$count);
');
} else { pp_addpm ('
my $st = pack ("L*", @$start);
my $ct = pack ("L*", @$count);
'); }
#------------------------------------------------------------------------------------------------------
pp_addpm (<<'EOPM');
# Call the correct 'put' routine depending on PDL type
if(ref($pdl) =~ /Char/) { # a PDL::Char type PDL--write a netcdf char
variable
$rc = PDL::NetCDF::nc_put_vara_text ($self->{NCID},
$self->{VARIDS}{$varnm}, $st, $ct, ${$pdl->get_dataref});
} else {
$rc = &{$typemap8{$pdl->get_datatype}}($self->{NCID},
$self->{VARIDS}{$varnm}, $st, $ct, $pdl);
}
croak ("put: Cannot write file -- " . PDL::NetCDF::nc_strerror ($rc))
if $rc;
$rc = PDL::NetCDF::nc_sync($self->{NCID});
croak ("put: Cannot sync file -- " . PDL::NetCDF::nc_strerror ($rc)) if
$rc;
return 0;
[email protected]
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611
On Fri, 17 Dec 2010, Sisyphus wrote:
> Hi Doug,
>
> Just a follow-up fyi - nothing here that you need to respond to :-)
>
> I've asked a couple of questions below - but you are quite free to ignore
> them. There's really no need to have a Windows x64 build of PDL-NetCDF. It's
> just something that would add "completion" to the list of PDL-NetCDF ppm
> packages that I already provide. (No-one has specifically requested an x64
> build of PDL-NetCDF for MS Windows.)
>
> In libsrc/v2i.c we have:
>
> #if SIZEOF_LONG == SIZEOF_SIZE_T
> [do stuff]
> #else
> [do other stuff]
> #endif
>
> For most compilers (including 32-bit MinGW), sizeof(long) == sizeof(size_t).
>
> But for the 64-bit MinGW compilers sizeof(long) is 4, whereas sizeof(size_t)
> is 8.
>
> Hence the x64 compiler runs different code to that run by the x86 (32-bit)
> compiler.
>
> Anyway, by adding a few additional includes at the beginning of libsrc/v2i.c,
> NetCDF-4.0.1 builds fine with the x64 compiler. Just the one failing test
> (see below my sig). I still haven't discovered where the NC struct is
> defined, but obviously it's taken care of by the addition of the extra
> headers I've included in v2i.c - which are:
>
> #include "nc.h"
> #include "rename.h"
> #include <string.h>
> #include <assert.h>
> #include "rnd.h"
> #include "utf8proc.h"
>
> So ... that all looks reasonably good, and PDL-NetCDF-4.05 builds fine with
> my x64 build of perl-5.12. (Not even any warnings.)
>
> However, the test suite does not provide such a good result. 01-Netcdf3.t
> hangs during test 4 when (in sub puttext) 'nc_put_vara_text()' is called.
> It's interesting (and perhaps pertinent) that this function takes both int
> and size_t* arguments.
>
> Could there be some problem with the PDL::NetCDF typemap, which maps int* and
> size_t* the same way ?
> Or perhaps the ExtUtils/typemap that's part of my x64 perl ? (It maps size_t
> and unsigned long identically.)
>
> I couldn't really come up with anything that demonstrated a problem with such
> mappings - but I'm not real smart when it comes to this stuff.
>
> To your knowledge, has PDL-NetCDF-4.05 been successfully built on a 64-bit
> build of perl where sizeof(int) == 4 && where sizeof(size_t) == 8 ?
>
> As regards t/02-Netcdf4.t, test 17 ("putslice with deflate") fails, and the
> test script aborts, with:
>
> put: Cannot write file -- NetCDF: Start+count exceeds dimension bound at
> t/02-Netcdf4.t line 43
>
> This happens when, near the end of sub putslice, the following call is made:
>
> $rc = &{$typemap8{$pdl->get_datatype}}($self->{NCID},
> $self->{VARIDS}{$varnm}, $st, $ct, $pdl);
>
> ($rc gets set to -57 ... which is true ... which triggers the croak().)
>
> Btw, thanks for the contributions you've made towards the resolution of the
> PDL segfaults (and other anomalies) ... nice work !!
>
> Cheers,
> Rob
>
> Haven't yet built NetCDF-4.1.1 properly. There's a tex2dvi.exe error during
> the make process (because I don't have TeX) which kills the build. By that
> time, however, the library has probably already been built, so I might yet be
> able to install it and give it a try ... or I can get a TeX installed
> (apparently MikTeX is suitable).
>
> Here's that failing test from the NetCDF-4.0.1 suite:
>
> *** Testing netcdf-4 variable functions, even more.
> *** Testing with classic format:
> **** testing simple fill value attribute creation...ok.
> **** testing simple fill value with data read...ok.
> **** testing fill value with one other attribute...ok.
> **** testing fill value with three other attributes...ok.
> **** testing fill value with simple example...ok.
> **** testing fill value with example from cxx tests in v2 api...16 failures
> *** Testing with 64-bit offset format:
> **** testing simple fill value attribute creation...ok.
> **** testing simple fill value with data read...ok.
> **** testing fill value with one other attribute...ok.
> **** testing fill value with three other attributes...ok.
> **** testing fill value with simple example...ok.
> **** testing fill value with example from cxx tests in v2 api...16 failures
> *** Testing with HDF5:
> **** testing simple fill value attribute creation...ok.
> **** testing simple fill value with data read...ok.
> **** testing fill value with one other attribute...ok.
> **** testing fill value with three other attributes...ok.
> **** testing fill value with simple example...ok.
> **** testing fill value with example from cxx tests in v2 api...16 failures
> *** Testing with HDF5, netCDF Classic Model:
> **** testing simple fill value attribute creation...ok.
> **** testing simple fill value with data read...ok.
> **** testing fill value with one other attribute...ok.
> **** testing fill value with three other attributes...ok.
> **** testing fill value with simple example...ok.
> **** testing fill value with example from cxx tests in v2 api...16 failures
> *** Testing with HDF5, netCDF Classic Model:
> **** testing simple fill value attribute creation...ok.
> **** testing simple fill value with data read...ok.
> **** testing fill value with one other attribute...ok.
> **** testing fill value with three other attributes...ok.
> **** testing fill value with simple example...ok.
> **** testing fill value with example from cxx tests in v2 api...16 failures
> **** testing create order varids...ok.
> **** testing simple variable renaming...ok.
> **** testing dimension and variable renaming...ok.
> **** testing endianness...ok.
> **** testing chunking...ok.
> **** testing contiguous storage...ok.
> **** testing extreme numbers dude...ok.
> **** testing error codes for name clashes...ok.
> **** testing error codes for name clashes some more...ok.
> **** testing error codes for name clashes even more...ok.
> **** testing error code for too-large chunks...ok.
> 64 errors detected! Sorry!
> Sorry! Unexpected result, tst_vars2.c, line: 351
> Sorry! Unexpected result, tst_vars2.c, line: 351
> Sorry! Unexpected result, tst_vars2.c, line: 353
> Sorry! Unexpected result, tst_vars2.c, line: 356
> [snip more similar]
> Sorry! Unexpected result, tst_vars2.c, line: 382
> Sorry! Unexpected result, tst_vars2.c, line: 383
> FAIL: tst_vars2.exe
>
> When I print those specified lines out, they just look like junk.
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
