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

[netCDF #EJA-190555]: netcdf42-fortran: netcdf.h for fortran not found by configure (= a script glitch?) (fwd)

Hi again,

> Overall:
> 
> Most of the lost time I had was due to netcdf and scripts.
> 
> I recommend:
> 
> For Fortran: All files in one big file. The compiler-options for Intel 
> (documented). The result, a *.obj file to be linked statically as in the
> "good old times", e.g. "safe but slow". This way one gets CESM running fast.
> 
> For all others who want it fast, lean, whatsoever: As you do it anyway.

We currently support both static linking and use of dynamic linking
with shared libraries.  Users overwhelmingly prefer the shared
libraries approach, because it makes linking so much easier.  Compare
the following two ways to link a Fortran program with netCDF, the
first using static linking and the second using shared libraries:

  fortran_compiler my_prog.f -o my_prog -I/opt/include \
    -L/opt/lib -lnetcdff -lnetcdf -lhdf5_hl -lhdf5 -lz -lcurl -lm

  fortran_compiler my_prog.f -o my_prog -I/opt/include -L/opt/lib -lnetcdff

Regarding compilers, the current netCDF Fortran library has been
tested on GNU compilers as well as Intel and PGI.
 
> In best(!) faith you think: Scripts are good. In reality, due to many 
> glitches, 
> they cause most of the trouble.

Yes, you're right, the configure scripts and cmake scripts we use
cause lots of problems.  But they also leverage our resources so we
can continue to develop, maintain, and support the software with only
2 staff, supporting thousands of users and lots of different
platforms, many of which we have no access to for testing.

> I want: Once I compile by plain compiler calls (ifort name options) the 
> file(s) 
> remain(!), get even burnt on CD, and work - metaphorically - for millions of 
> years.

You have the choice of building your programs with static linkage
instead of dynamic (shared), and that will give you what you want.
The default for the libraries is to provide both static and shared
libraries, but you can disable the generation of shared libraries with
the --disable-shared configure option.

When using static libraries, it's harder to get the linking flags
right, but once you succeed, it will work for as long as the platform
exists.

> Rebuilding auxiliary libraries (netcdf, mct, pio and such) I really do not 
> like.
> The CESM will get changes by me and for that netcdf is auxiliary.
>
> And: A 100% Fortran-Version. I have an own for netcdf3 "all fortran" that 
> works 
> on CDF-files (ASCII) "reverse-engineered" following the documentation.
> On the binaries I have no documentation. If you make the netcdf-library "all 
> Fortran" all these problems will disappear.

Recently we've made progress on utilizing the new C compatibility
features in the Fortran 2003 and Fortran 2008 standards, providing a
portable and standard way to call C functions from Fortran.  Although
rewriting the netCDF libraries in Fortran has definite benefits for
Fortran developers, it's not practical for Unidata to lead such an
effort, given the small number of staff currently developing,
maintaining, and supporting netCDF.

By supporting advanced features in the C library and building other
libraries on top of that for Fortran, Python, and Java, we're able to
leverage our efforts to create maintainable software for scientific
data access.  We have also had some success in enlisting other
open-source developers to contribute to our efforts by moving the
software repository to GitHub.

I'm impressed that you were able to develop an all-Fortran
implementation of netCDF-3, just by reverse-engineering the format and
API specifications!  Perhaps by making your implementation available,
others could help to extend and enhance it to provide an easier path for
other Fortran developers.

> For all others: As you do it anyway.

Thanks for your suggestions and feedback!

--Russ

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: EJA-190555
Department: Support netCDF
Priority: Normal
Status: Closed