Orion Poplawski <orion@xxxxxxxxxxxxx> writes:
> On 07/31/2009 09:48 AM, Ed Hartnett wrote:
>>
>> Added libcf library to netCDF distribution. Turn it on
>> with configure option --with-libcf.
>
> I see that there is a separate web page for libcf. Will this be
> released separately from netcdf? Are there issues if it is compiled
> sepearately from netcdf? Just trying to look at it from a Fedora
> packager's perspective.
It will be release separately as well.
Libcf requires netcdf, but will build either with the netCDF
distribution, or separately, when pointed at an external netCDF install.
>
>> Added UDUNITS2 to the distribution. Use --with-udunits
>> to build udunits along with netcdf.
>
> Looks like udunits is configured (if not necessarily built) even if
> --with-udunits is not specified or if --with-udunits=no is specified.
> I think you want to conditionally add udunits to AC_CONFIG_SUBDIRS if
> possible. Also, not sure what the default is. configure --help
> doesn't specify.
Conditionally running the configure causes problems for autotools.
> Similary to above, Fedora packages udunits separately. Will netcdf
> still be able to make use if it if --with-udunits is not specified.
Yes, UDUNITS is completely separate, whether installed from the netCDF
distribution or stand-alone. It does not use the netCDF library at all.
> Also, with --enable-install-doc I'm seeing documentation installed into:
> "/usr/share/doc/netcdf /usr/doc/netcdf-4.1-beta2-snapshot2009082800/"
> Seems to be caused by rules like:
>
> if INSTALL_DOCS
> docdir += $(prefix)/doc/$(PACKAGE)-$(VERSION)
> doc_DATA = $(pdf_docs) $(html_mans) $(txt_docs) $(ps_docs) \
> $(info_docs) $(html_docs)
> endif
>
> in man4/Makefile.am.
OK, I have changed the way the documentation is installed. Thanks for
pointing this problem out.
>
> Next, looks like tst_suiterunner is not linked against -lmfhdf. This
> is from a Fedora Rawhide build on x86_64 - build log here:
>
> http://koji.fedoraproject.org/koji/getfile?taskID=1641990&name=build.log
>
> /bin/sh ../libtool --tag=CXX --mode=link c++ -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m64 -mtune=generic -L/usr/lib64/hdf -o
> tst_suiterunner tst_suite.o tst_suiterunner.o
> ../cxx4/libnetcdf_c++4.la ../libsrc4/libnetcdf.la -lhdf5_hl -lhdf5
> libtool: link: c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
> -mtune=generic -o .libs/tst_suiterunner tst_suite.o tst_suiterunner.o
> -L/usr/lib64/hdf ../cxx4/.libs/libnetcdf_c++4.so
> ../libsrc4/.libs/libnetcdf.so -L/usr/lib -L/lib -lcurl -lhdf5_hl
> -lhdf5 -Wl,-rpath -Wl,/usr/lib64
> ../libsrc4/.libs/libnetcdf.so: undefined reference to `SDstart'
> ...
Ummm, what is tst_suitrfunner?
> Also, not sure if you are aware but the netcdf build is not parallel
> capable (ie make -j N will fail). Would be nice in these days of
> proliferating cores...
Make -j works for me...
> Finally, getting a test failure on Fedora 11 i586 (build log attached)
>
> HDF5-DIAG: Error detected in HDF5 (1.8.3) thread 0:
> #000: H5Tnative.c line 119 in H5Tget_native_type(): cannot retrieve
> native type
> major: Invalid arguments to routine
> minor: Inappropriate type
> #001: H5Tnative.c line 175 in H5T_get_native_type(): not a valid size
> major: Invalid arguments to routine
> minor: Inappropriate type
>
> *** Checking HDF5 attribute functions some more.
> *** Creating tst_xplatform2_3.nc with HDF only...Sorry! Unexpected
> result, tst_h_atts3.c, line: 171
> HDF5-DIAG: Error detected in HDF5 (1.8.3) thread 0:
> #000: H5T.c line 1707 in H5Tclose(): not a datatype
> major: Invalid arguments to routine
> minor: Inappropriate type
> free types 0 free types 1 free types 2 Sorry! Unexpected result,
> tst_h_atts3.c, line: 184
> 2 failures
> 2 errors detected! Sorry!
> FAIL: tst_h_atts3
You must upgrade to HDF5-1.8.3-snap2 to fix this (1.8.4 is coming out
soon as well).
Thanks,
Ed
--
Ed Hartnett -- ed@xxxxxxxxxxxxxxxx
