Hi Russ,
The HDF4 configure has an option "--includedir=/xxx/yyy" which allows
you to specify which directory to install the HDF4 include files to.
The default is $prefix/include, which caused problems for us in the past
because it would clobber "netcdf.h" from th NetCDF build.
To fix the problem you pointed to below, could the NetCDF configure
option allow for something like "--hdf5libdir" if "--with-hdf5" is not enough?
Or is this non-standard?
I found that with NetCDF 4.1.3, in addition to setting LIBS, CPPFLAGS and
LDFLAGS, I also had to edit configure and change
LIBS="-lcurl $LIBS"
to:
LIBS="-lcurl -lssl -lldap -lidn -lrt $LIBS"
because configure was failing on the "curl_easy_setopt" test. This line is
different depending on what system I'm building on.
I have the LIBS environment variable set to "-lhdf5_hl -lhdf5 -lz -lm -lsz'"
in order for the HDF5 configure tests to not fail. I haven't tried adding
the above curl lines to my LIBS env var yet. I was in a hurry and didn't
try to do it the "cleaner" way.
--Mary
On Aug 2, 2011, at 2:52 PM, Russ Rew wrote:
> Hi,
>
> Dropping use of the "--with-..." syntax to specify where configure
> should find installed libraries was intended to fix a couple of serious
> bugs in building netCDF, as described here:
>
> https://www.unidata.ucar.edu/jira/browse/NCF-20
>
> I also wondered why we couldn't at least provide an error message when
> "--with-hdf5=..." was given as a configure option, because we do provide
> an error message for unsupported options such as "--tooth-fairy".
> However, that would actually violate an autoconf rule:
>
> Sorry, but --with-XXX= options must not be error'd out, as an autoconf
> convention. Some other organization might well create a configure
> which includes netcdf, as well as some other package that
> (coincidentally) uses --with-hdf5=. In this case, if we error'd out,
> that would break a configure which would otherwise be expected to
> work.
>
> So although --tooth-fairy will fail, --with-anything will not, because
> configure will assume that you wish to pass it to another configure
> running as a subconfigure.
>
> Autoconf moves in a mysterious ways, its wonders to perform.
>
> We're sorry for the problems caused by changing the way the library is
> built, but the motivation was fixing bugs rather than making it more
> convenient for us. The support questions about this issue have
> definitely made more work for us ... :-)
>
> Ed may have more to say about this when he's back at his keyboard.
>
> --Russ
>
>> I have to admit that I too wax nostalgic for the --with-hdf5 days. (I
>> still haven't been able to get 4.1.3-beta1 to build, so I'm sticking
>> with 4.1.1 for the foreseeable future.)
>>
>> On Aug 2, 2011, at 12:43 PM, Jennifer Adams wrote:
>>
>>> I agree with everything in this post, building 4.1.3 has become a
>>> gigantic pain. And I didn't look in the release notes to see that the
>>> --with-hdf5 option had been eliminated and was baffled by why all the
>>> configure test programs were having trouble finding my hdf5 and szip
>>> builds. Now I have read the release notes and I see you are passing
>>> your pain onto your users. Humph! There ought to be a warning right at
>>> the beginning of the configure script, when it parses the args and
>>> switches, and also in the --help output if possible. I see the new
>>> configure setup as being broken because of all the flags that need to
>>> be set/unset, which is not the way it should be -- none of the other
>>> 25 libraries I have to build for GrADS work this way. What is the
>>> presumed standard way of finding libraries? Please add some
>>> documentation with guidance for the best way to proceed without the
>>> --with-hdf5 (et al.) options. Does hdf5 library need a hdf5-config
>>> file or a pkgconfig file? Should we lobby the HDF Group to implement
>>> such a thing, because this new set up is really awful.
>>> --Jennifer
>>>
>>>
>>> On Aug 2, 2011, at 11:07 AM, Fabr=EDcio Zimmerer Murta wrote:
>>>
>>>> I've just read in the NetCDF's release notes the following, for
>>>> the 4.1.3-beta1 version from 2011-04-29:
>>>>
>>>> "Took out --with-hdf5 and related options due to high
>>>> cost of maintaining this non-standard way of finding
>>>> libraries."
>>>>
>>>> Now, to the facts:
>>>> 1. this option forces people with custom HDF5 libraries to manually
>>>> change CFLAGS, FCFLAGS and LDFLAGS in compile time.
>>>> 2. NetCDF 4.1.3 requires HDF5 1.8.6
>>>> 3. Current linux distros comes with just HDF5 1.8.4
>>>>
>>>> Result: You removed the option to select HDF libraries when it would
>>>> be most needed as everyone is needing to install custom HDF5 library
>>>> on their computer. This makes people lifes a lot harder, you know? I
>>>> am planning on shipping NetCDF and HDF5 as nested packages with a
>>>> project we are doing due to excessive compile problems, and we will
>>>> be forced to add back AC_WITH_ARG for HDF5 in NetCDF provided
>>>> package, in order for it to work in accordance with the main
>>>> package's arguments.
>>>>
>>>> And, why did you call the AC_ARG_WITH option a non-standard way to
>>>> find libraries? I thought it was a standartizing attempt from GNU
>>>> autotools to aid in linking to packages...
>>>>
>>>> - fabricio
>>>>
>>
>> --
>> Dr. Christopher Lynnes NASA/GSFC, Code 610.2 phone: 301-614-5185
>
> _______________________________________________
> netcdfgroup mailing list
> netcdfgroup@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
