On 15 Jan 2006 23:09:46 +0100, Thomas Walter <[EMAIL PROTECTED]> wrote: > Hello, > > On Sun, 2006-01-15 at 22:36, Igor Khavkine wrote: > > On 1/4/06, Juan Antonio Añel Cabanelas <[EMAIL PROTECTED]> wrote: > > > I opened an ITP for Gnudatalaguage (GDL could be confusing in Debian > > > because it is similar to "Gnome Development Library") 9 months ago. > > > > > > It exist some problems with libraries, GDL is a complex package, but a > > > friend of mine and my sponsor, DD, has packaged a GDL version with > > > without support for HDF files and it is not tested. > > > > Let me take a guess at why HDF support was turned off. I just tried > > compiling the latest release of GDL (0.8.11) and ran into a problem. > > The problem has to do with the netcdf.h header file. In Debian, it can > > be found in two packages: > > > > libhdf4g-dev: usr/include/hdf/netcdf.h > > netcdfg-dev: usr/include/netcdf.h > >
> > When all the features are turned on, GDL wants both the HDF4 and > > NetCDF libraries to be available. The header file it really wants is > > from the netcdfg-dev package. However, if HDF4 support is turned on, > > the -I/usr/include/hdf gets passed to gcc. Hence, the header file from > > libhdf4g-dev will always take priority over the other one, since > > netcdfg-dev puts it into the standard include path. > > I think there should be found a solution which allows both. > As far as I know, the best would be to use HDF5 and perhaps combined > with netCDF-4 project to get he benefit of both. Campatibility and > simplicity from CDF and the rich data model from HDF5. I should mention that, when all compile time features are enabled, GDL wants both the HDF4 and HDF5 libraries. > > The two easiest solutions to this problem is to either replace every > > instance of <netcdf.h> in GDL by "/usr/include/netcdf.h" (after which > > everything compiles fine) or to hack the Makefiles to remove the HDF > > directory from the include path for the few source files that cause > > problems. However, given that there is at least one application that > > encounters this problem, does it make sense to try to fix this at the > > level of the packaging of netcdfg-dev? For instance, GDL itself tries > > to look for NetCDF headers in /usr/include/netcdf-3. > > That would result in a loss to use the improved data functionality of > HDF5. I'm not sure what you mean here. Under optimal circumstances, GDL wants to use all of NetCDF-3, HDF4, and HDF5. My question was whether the it is best to fix the above problem by patching the GDL source or changing the location of header files in netcdfg-dev. Igor
