Re: szlib build problems...

Elena Pourmal <epourmal@xxxxxxxxxxxx> writes:

> Ed,
>
> I am curious on which system did it happen. I can suspect only Solaris.
>
> Elena
>

Well despite your suspicions it was linux!

But it is my development machine,which has a lot of weird stuff going
on!

Ed
-- 
Ed Hartnett  -- ed@xxxxxxxxxxxxxxxx

==============================================================================
To unsubscribe netcdf-hdf, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================

>From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 09 2003 Jul -0600 10:34:00 
Message-ID: <wrxu19v7j7r.fsf@xxxxxxxxxxxxxxxxxxxxxxx>
Date: 09 Jul 2003 10:34:00 -0600
From: Edward Hartnett <ed@xxxxxxxxxxxxxxxx>
To: netcdf-hdf@xxxxxxxxxxxxxxxx
Subject: more on netCDF 4 compatibility requirements...
Received: (from majordo@localhost)
        by unidata.ucar.edu (UCAR/Unidata) id h69GY1gj029346
        for netcdf-hdf-out; Wed, 9 Jul 2003 10:34:01 -0600 (MDT)
Received: from rodney.unidata.ucar.edu (rodney.unidata.ucar.edu 
[128.117.140.88])
        by unidata.ucar.edu (UCAR/Unidata) with ESMTP id h69GY0Ld029340
        for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Wed, 9 Jul 2003 10:34:00 -0600 (MDT)
Organization: UCAR/Unidata
Keywords: 200307091634.h69GY0Ld029340
Received: (from ed@localhost)
        by rodney.unidata.ucar.edu (8.11.6/8.11.6) id h69GY0B15492;
        Wed, 9 Jul 2003 10:34:00 -0600
Lines: 40
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netcdf-hdf@xxxxxxxxxxxxxxxx
Precedence: bulk


Howdy!

Here's some more detail on what we expect netCDF 4 to be able to
do. Please let me know what you think...


* NetCDF File Format Compatability

** NetCDF 4 uses HDF5 as it's storage layer.

** NetCDF 4 can also create/read/modify files created with previous
   versions of netCDF, using the original netCDF data format.

** If the user opens an old netCDF file, and attempts to modify it,
   NetCDF 4 will stick with the (old) netCDF file format. New API
   features (like bit-packing) won't work on these files.

** There will be a way for users to cause an old netCDF file to be
   copied into the new HDF5 data format.

** NetCDF 4 can read files created with HDF5, but some features will be
   inaccessible (rasters, for example). Certain group conventions may
   be required for a HDF5 file to be accessible via netCDF.

** NetCDF 4 can't read HDF 4 files.

** NetCDF 4 has no knowledge of HDF-EOS.



* NetCDF API Backward Compatibility

** Interface will be added to, but all existing function calls will
   remain the same, so that programs written for netCDF 3.x will work
   for netCDF 4.0 with a simple compile.

** By default, the netCDF 4 API creates HDF5 files. A renamed set of
   functions allows access to the original 3.x netCDF functions, which
   allow the users to create netCDF format files.