NOTE: The netcdf-porting mailing list is no longer active. The list archives are made available for historical reasons.
J Luis <jmfluis@xxxxxxxxx> writes:
>>> I built netcdf4.1.1 and 4.1.2beta 32 and 64 bits with VS2010. In all
>>> builds the nc_test.exe pass all but 3 tests that are
>>>
>>> Â Â Â Â FAILURE at line 105 of ..\..\..\nc_test\test_read.c: nc_open
>>> of non-netCDF file: status = 2
>>> Â Â Â Â ### 1 FAILURES TESTING nc_open! ###
>>
>> Seems like what is happening here is that the test is trying an open of
>> a file that is not a netcdf file, and getting an error code of 2 instead
>> of the expected error code of -51 (NC_ENOTNC - not a netcdf file).
>>
>> Does the file that is being opened exist?
>
> Good guess.
> No the file does not exist but note that we are talking of test
> program -- "nc_test" -- that ships with the with netcdf package.
> The line in question has
>
> err = nc_open("nc_test.o", NC_NOWRITE, &ncid);/* should fail */
>
> If I create a dummy "nc_test.o" file than the tests pass.
Ah ha! The nc_test.o would be present for a Unix-based build. For
windows, this won't work!
I have added a Jira ticket for this as a bug fix. Follow the action
here:
https://www.unidata.ucar.edu/jira/browse/NCF-121
>
>>> Now, I cannot be absolutely sure (... but almost) that this is the
>>> same reason why GMT crashes in a test where at a certain point it it
>>> attempts to open a non-netcdf file.
>>
>> Not sure what GMT is...
>
> Ah, sorry. GMT (http://gmt.soest.hawaii.edu/) is one of your oldest
> 'clients'. It uses netcdf for 20 years but up to now with 3.6.x
> series.
Wow, looks very nice!
I would certainly love to stop by and learn more about it! ;-)
> I am trying to move to netcdf4 but this crash (Windows only) is a show
> stopper.
>
> BTW the test 64 bits version of "nctest" crashes on the "ncsync" step.
> The debugger shows that this happens at line 709 of
>
> ......\netcdf-4.1.2b\nctest\cdftests.c
>
> if (ncvarput(ncid0,dd_id,dd_start,dd_edges,(void *)dd_vals) == -1) {
>
> where ncid0 has the suspicious value of 65536
The value is not suspicious. NetCDF-4 ncids represent more than just a
file, they also include an integer for the group. The file number is
stored in the first 16 bits, the group in the final 16 bits.
This is all part of the v2 API. Unless you are using the v2 API, I
suggest you simply disable it. It is provided for backward compatibility
only.
For windows builds, just don't include the libdispatch/v2i.c code, and
set the preprocessor macro NO_NETCDF_2. And then don't run any of the
tests under nctest. (There are also some v2 tests scattered about in
other directories, which should also be turned off.)
The V2 API does provide some additional testing for the build, but the
v3 API tests are already very comprehensive. Certainly no one should be
writing new code with the v2 API.
> Thanks, but not really useful. We build a pure Windows package where
> netcdf is only of the libraries. I don't know more and don't want to
> mix Mingw and VS dlls. And I want also be able to compile 64 bits
> versions.
> Joaquim
OK, thanks Joaquim!
I am reconsidering my decision to go with mingw. It's proved to be
rather problematic, and, guess what, not what anyone actually
wants. This is a classic engineering mistake, and if I had gotten a
tattoo every time I made it, I would be having a hard time finding an
empty patch of skin for a new one.
So now I think the best way to proceed would be an officially sanctioned
windows build with visual studio. We would then keep it up to date with
the unix-based build system.
Thanks,
Ed
--
Ed Hartnett -- ed@xxxxxxxxxxxxxxxx
netcdf-porting archives: