[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 Peter,

> 1) Thankyou for your answers.
> 
> 1a) netcdf for C (as you wrote is required) existed already but in a
> different directory.
> I built it again to be put into /usr/local with subdirectories, such as
> (...)/lib. The netcdf-c ran through,
> e.g. with "./configure (...)", "make check install" and the
> "congratulations screen".
> 
> 1b) Then I went into the directory netcdf-fortran-4.2.
> 
> Running ./configure with --prefix=/usr/local --disable-netcdf-4
> --disable-dap
> produced:
> 
> 1b1) in config.log: various errors of the type "size cannot computed",
> missing declaration (or so) - but it continued.
> 
> Original Redhat Linux from the CD, e.g. I bought the complete
> distribution-pack which Redhat offers so it is as "Original" as
> possible (tough the university has various Linuxes).

There will always be many errors in config.log, because it logs attempts
to determine characterisitics of the platform by running tests.  So you
should ignore all error messages in config.log, unless the configure 
script fails to complete and generate Makefiles.

> 1b2) configure 19770: ./conftest
> libnetcdf.so.7: cannot open shared library objectfile: No such file or
> directory.
> 
> Looked into /usr/local/lib : It exists (link to a file).
> libnetcdf.so.7.2.0 exists as well ("original" file, 1.2 MB).
> It _is_ the "new" file, e.g. what I made again some 30 minutes ago.
> 
> Then I deleted the "Link" and copied libnetcdf.so.7.2.0 onto
> libnetcdf.so.7. Some 1.2 MB more I don't mind.
> 
> It produced the same error.

So you probably need to set the LD_LIBRARY_PATH environment variable
to include /usr/local/lib, assuming that's where the netCDF C library
was installed.  The need for this is explained in the instructions for 
building the netCDF Fortran library:

  http://www.unidata.ucar.edu/netcdf/docs/netcdf-fortran-install.html

If that's not the problem, we'll need to see your config.log file from
the attempt to configure and build the netCDF Fortran software.

> ****************
> 
> I ran all these configures under the user, e.g. logted in a "normal
> user", not as root.

Good, you can run everything as a normal user except for "make install",
which you may have to run as root after all the tests pass if you are
trying to install the libraries and include files in a directory owned 
by root.

> The permissions are accordingly. I added in addition read and write but
> the error persists.
> 
> The resulting error is: cannot compute sizeoff(something).

Is this error from running configure, and was it the last error before
configure exited with an error?

Or is it from running "make" or "make check" after configure completed 
successfully?

> So: Where to put the libnetcdf.so.... file?

You should not manually put it anywhere.  The "make install" command
installs it under the directory you specified in the --prefix= option,
or under /usr/local/lib by default.  The "make install" also creates
necessary symbolic links and installs all the other needed files, 
including header files and executable commands.  It would be take a lot
of time to install all these files manually, and it would be easy to
make an error.

> 2) Now to the netcdf3(Fortran), ESMF (Fortran), both reverse-engineered,
> and other (a mini-timing):
> 
> "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."
> 
> 2a) I "nc-dumped" the *.nc files of ccm3.6 / an early CESM.
> This way they became ASCII-files that are in-line with the documentation
> of the APIs.
> This way I could write programs that work on them.
> I ran ccm3.6 / the early CESM with the respective "initialization-files"
> and wrote respective output-files by ccm3.6 / the early CESM.
> It worked with the Salford-Compiler (F77, F90) and then the Intel Fortran
> (IVF in command-mode).
> 
> Which is: For _that_ it is tested. Same the ESMF.
> 
> This means: It processes files _either_ to read _or_ to write, e.g. the
> way ccm3.6 does it.
> That(!) would suit many users who "fight" with netcdf.
> 
> On other things, such as "interactive file processing" I cannot comment.
> 
> I can send it to you ("as is"), and if you like, "fine-tune" it. E.g.
> based on emails by you what you want.
> 
> Such as "do test xyz" using routines abc. I will do that on the weekends.
> It reads (somehow) sequential as "nc-dumped" files are (including
> Backspace, Rewind etc.)
> 
> Adding a "binary-version", that reads/writes netCDF-files "natively"
> (direct-access) requires a documentation of the binary format.
> For example: If it is "direct access" or "comparable" (sequential but
> "positions-computed").
> 
> Reading for example "Bytewise" in in Fortran NO(!!!!!) problem, even(!)
> from F77 (extended) on (Intel, Watcom, Salford),
> 
> If you have a documentation, e.g. how you made the C-version (wat it
> reads/writes where), I am happy to look into it and "glue" a "binary-read"
> / "binary write" to it (in Fortran).
> 
> From the Fortran-Side it is possible.
> 
> CESM1_2_1 has however much more files than ccm3.6 the early CESM.
> As I do not know whether they changed also things there I decided to do it 
> (first) with
> the "official" netcdf (to get geology into CESM) and do the Fortran-part
> later if needed.
> 
> Having said above I can send it to you.
> It is an extended F77, e.g. F77 plus "allocate".
> 
> Regarding the ESMF: It is same (all Fortran). It provides the
> functionality as required by ccm3.6 / the early CESM (= you can have it).
> 
> 2c) If for mpi / mpi-serial a documentation exists, I think I will make a
> F77(extended)-version too.
> E.g. (1) the "logic" and (2) the APIs.
> 
> The reason: The Intel Fortran does "openmp" anyway. With that parallelism
> systems with a low number of processors / cores (Quadcore for example)
> are "well served".
> For such configurations mpi-serial is the best.
> 
> Of course: If I have it as mpi-serial (in Fortran) I can later make an
> mpi-parallel in Fortran (reverse-engineered as well).
> I need the documentation for it, e.g. APIs and what they do.
> 
> My line is: To have it CESM-compatible.
> 
> I suggest: I first get CESM_1_2_1 running with the official netcdf.
> Then I do that run with my netcdf.
> Then, if it works fine (as I think it will), I send it to you, including
> "how I connected it with CESM".
> 
> As you work fr thousands of users with two persons I think that is the
> best approach.

That sounds best to me also.  I cannot commit that we will have the resources
to do anything with it, but I'd at least like to look at it, as time permits.

Thanks!

--Russ

> Kind regards
> 
> Peter
> (Dr. Peter P. Smolka)
> 
> -----Ursprüngliche Nachricht-----
> Von: Unidata netCDF Support [mailto:address@hidden]
> Gesendet: Mittwoch, 19. März 2014 13:15
> An: address@hidden
> Cc: address@hidden
> Betreff: [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
> 
> 
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