<div class="gmail_quote">On Tue, Feb 26, 2008 at 6:07 PM, Christian Marquardt &lt;<a href="mailto:marquardt.christian@gmail.com">marquardt.christian@gmail.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hmm.<br>
<div class="Ih2E3d"><br>On Tue, Feb 26, 2008 at 6:18 PM, Arlindo da Silva &lt;<a href="mailto:dasilva@alum.mit.edu">dasilva@alum.mit.edu</a>&gt; wrote:<br>&gt;<br>&gt; Yes, kinda. I believe the netcdf routines are still there with a different<br>
&gt; (mangled) name. However, supplibs-2.0.1 contain a more recent version of<br>&gt; hdf4. So far I&#39;ve trying to keep the builds consistent across all the<br>&gt; platforms (using same version of the libraries).<br><br>
</div>They (the HDF maintainers) changed the handling of the internal netcdf<br>library, if I remember correctly... In 2.0.1, you are using the newly<br>introduced --disable-netcdf so that it&#39;s not build any more (and<br>
gradshdf can&#39;t be build for GrADS 1.9).In 2.0.0, the HDF-internal<br>netcdf is still build... Is there a reason why that has been disabled?</blockquote>
<div>&nbsp;</div>
<div>Yes: grads v2 links against netcdf *and* hdf.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span id=""></span><br>I thought that the setup of the supplibs as you use it allows for<br>different versions of, say, netcdf.<br>
</blockquote>
<div>&nbsp;</div>
<div>Yes, you could have this flexibility. However, at this point is more of a configuration management issue. When I updated hdf-4 to the latest release I had already made all those builds of v1.9 with the previous hdf4 which seemed to work just fine. I wasn&#39;t willing to spend the time and redo all the builds with the new hdf4.&nbsp;What I am trying to do is to have&nbsp;absolutely the same version of the libraries across all the builds, otherwise it gets&nbsp;hard&nbsp;to track down bugs (I&#39;ve been down this path). If there is ever going to&nbsp;be another v1.9 release then I&#39;ll unify the supplibs.&nbsp;</div>

<div>&nbsp;</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span id=""></span><br>I&#39;ve tried rebuilding the supplibs without disabling HDF&#39;s internal<br>netcdf, and GrADS 1.9 compiled absolutely fine (and passed all unit<br>
tests) with the newer version. </blockquote>
<div>&nbsp;</div>
<div>I believe you, it should.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span id=""></span>I didn&#39;t try grads 2.0, though. Could<br>one maybe support both with the same version of the supplibs?<br>
<font color="#888888"></font></blockquote>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>It will not work. Both hdf-4 and netcdf-3 will collide as they provide the same functions. What you can do is to eliminate netcdf-3 altogether, and have hdf-4 handling the input of both hdf and netcdf files. In fact, this is how it used to be done until v1.7 when LATS was introduced (hdf can only write hdf). However, once grads 2 offers netcdf/hdf output we would be in the same situation of 2 executables (gradsnc/gradshdf) if you eliminate netcdf-3, something I am glad Jennifer has been able to move away from.</div>

<div>&nbsp;</div>
<div>&nbsp;&nbsp; Arlindo</div></div><br>-- <br>Arlindo da Silva<br><a href="mailto:dasilva@alum.mit.edu">dasilva@alum.mit.edu</a>