[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #IMK-675971]: mac os x and netcdf 4.0.1

> Hello -
> I'm not a mailing-list subscriber, but I thought I'd let you know my
> experiences debugging the _H5P_CLS_FILE_ACCESS_g problem described on the
> netcdf website
> http://www.unidata.ucar.edu/software/netcdf/docs/known_problems.html#o_problem_mac
> .
> 
> The problem, according to the web site, is buiding with "-O2" rather than
> "-g". This is incorrect information.
> 
> After some debugging, I discovered that the real problem is that the
> "configure" script for netcdf-4.0.1 does not correctly add linker flags for
> the HDF5 library. (This was all tested under the MacPorts version of netcdf
> with "--enable-netcdf-4 --enable-ncgen4 --with-hdf5=${prefix}
> --with-szlib=${prefix}".
> 
> (On MacPorts, ${prefix} point to /opt/local - the macports install root.)
> 
> To fix the problem, I simply ran:
> 
> LDFLAGS=-L${prefix}/lib LIBS=-lhdf5 configure [... options ...]
> 
> And this produced dylib files with the correct linkage.
> 
> If you look at the Makefiles that autotools creates with and without the
> environment variables above, you'll notice that in the "libsrc4" directory
> there is no mention of the hdf5 library... even though things like the
> iconv, zlib, and szlib are added correctly.

I would like to fix this problem in the build files, but I can't quite tell 
what is going on from your email. When I build, the hdf5 library (and hdf5_hl 
library) are correctly linked in the libsrc4 directory:

/bin/sh ../libtool --tag=CC   --mode=link cc  -g -O2 -L/machine/local/lib      
-o tst_h_files tst_h_files.o libnetcdf.la -lhdf5\
_hl -lhdf5 -lz

Can you be more specific about the problem?

Thanks,

Ed

Ticket Details
===================
Ticket ID: IMK-675971
Department: Support netCDF
Priority: Critical
Status: Closed