Re: cfortran.h

  • To: Ed Hill <ed@xxxxxxx>
  • Subject: Re: cfortran.h
  • From: James Gallagher <jhrg@xxxxxxx>
  • Date: Mon, 18 Dec 2006 10:46:39 -0700

On Dec 18, 2006, at 10:00 AM, Ed Hill wrote:

On Mon, 18 Dec 2006 07:48:52 -0700 Ed Hartnett <ed@xxxxxxxxxxxxxxxx>

Jeff Whitaker <jswhit@xxxxxxxxxxx> writes:

Warren Turkal wrote:
The cfortran.h file is in /usr/include on Debian systems after
installing the cfortran package. Does netcdf use a cfortran.h in
/usr/include instead of the one within the tarball when it is
available? If not, could you please change netcdf to do so for


Warren:  Why?  What if it is broken, or out of date?  I'd rather
netcdf use it's own cfortran.h, which it knows it can trust.


NetCDF includes it's own cfortran.h, which will be used in its build.

Any cfortran.h on the system will not be used, it will be ignored by
netCDF. The netCDF fortran API looks for, and uses, its own
cfortran.h, not depending on it to be installed, or using it if it is.

This is necessary: some modifications to netCDF's cfortran.h allow it
to be built on even more platforms than the original cfortran.h

Hi folks,

I can appreciate "both sides" of this issue!  :-)

As a developer, its nice to sometimes use a locally included copy of
some 2nd-party software since, that way, you know its there and you
know exactly what version it is (inc. any changes you made to it).

As a packager for Fedora I can appreciate why most distros try to
eschew locally included copies of dependent software (usually libraries)
since they can be problematic:

  1) security headaches (eg. that local copy of zlib that a
     package includes is OLD and has known security holes which will
     mean that an updated system-wide zlib package will totally fail
     to fix your local problem)
  2) unnecessary bloat
  3) local copies are essentially "forks" which increase overall
     maintenance costs and tend to slow the movement of fixes into
     the respective upstream projects

Since cfortran.h is not a library, I think its quite unlikely to result in security problems. And its a single file so not a lot of bloat. So
most of the reasons against local inclusion are mooted.

However, it would be a shame to maintain local improvements in the
"netCDF version of cfortran.h" without submitting them to the upstream
project so that everyone can benefit. If its possible [0], I would urge
the netCDF folks to work with upstream so that everyone can benefit
from any "netCDF local" cfortran.h improvements.

I second this! I've found that it's much easier to send improvements 'upstream' than to maintain them myself. I've done this with curl/ libcurl and a few others.



[0] - Yes, this assumes that "upstream" projects are actively
      maintained and receptive to patches.  Which is not always
      the case...!  :-/

Edward H. Hill III, PhD  |  ed@xxxxxxx  |

James Gallagher                jgallagher at
OPeNDAP, Inc                   406.723.8663

To unsubscribe netcdfgroup, visit: