This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> Hi again Ed, > > > > > That is right, but "configure" will tell if the F77 and/or F90 > compilers are set up. If not, no fortran code will enter the netcdf > share library in the first place. So when compiling from scratch > there should not be an issue. Distributing binaries with or without > F77/F90 support is the only thing that becomes more complex. The problem is when there *is* f90 on the machine. In that case, even a C-only program will not build and run for me without being able to find the F90 libraries. > > > > > Do you think this is a bad idea? Would you like to try getting the > > combined shared > > library working? It is easy to change the configure script, but > > then the build breaks for me. > > As said, I'm now convinced that for the time being (probably until > GCC 4.1 or 4.2 comes with gfortran standard built in, it is wiser to > keep the fortran shared library separate. Just to make the transfer > of binaries easier, and probably shortening the loading time of C- > only programs that call the netcdf shared library. I am using gcc 4.1, which comes with gfortran. But this is not the only fortran compiler we have to support. > > > Any thoughts would be most welcome. This is our first release with > > shared library support so we are feeling our way forward carefully > > and would welcome > > any informed input. > > > > Do you use shared libraries a lot? If so, why? > > Yes, I use shared libraries a lot. I've been doing so ever since I > worked on an RS6000 that had that capability about 10 years ago. It > makes the binary executables SO much smaller. I've been making shared > libraries whenever I could since then on Linux and now on Mac OS X. > As a developer for GMT (Generic Mapping Tools), I've been working to > get the shared library support for Mac OS X in there too. GMT has > some libraries of its own and uses netCDF in all its ~50 programs. > You can imagine that the duplication of binary code gets tremendous > when you are creating a package with that many programs. > Thanks. > > Incidently, some of the docs have been updated, but until the next > > beta release you > > would have to do "./configure --enable-docs && make" to build it, > > and it will only work if you have a recent texinfo and tex > > installation, and tex is somewhat weird - it works > > for me on some machines but not others. > > It works for me on Mac OS X without a problem. But keep packaging > WITH the pdf files in there, since not everybody will have TeX set up > on their computers. > Yes, that is the intention. > > > > However, you can give it a try, and if it works you will find the > > latest documentation > > in the man directory, as text, pdf, info files, web pages, etc. > > > >> > >> 2) In all the manuals, after netcdf calls there is: > >> > >> if (status.ne.nf_noerr) call handle_err(status) ... or similar in > >> case of C and F90 > >> > >> However, handle_err(status) already checks against nf_noerr, so the > >> if-statement is superfluous. > >> It would be much cleaner simply to write after the netcdf calls: > >> > >> call handle_err(status) > >> > >> In fact, I use a short-cut to that and use, for example: > >> > >> call handle_err(nf_close(ncid)) > >> > >> Just a suggestion. But I think a useful one. > > > > Thanks, I will pass that on to the author of that code and see what > > he thinks. > > > > Where are you finding the handle_err() funtion anyway? > > It is not in the distro, but it is spelled out earlier on in each of > the manuals. For example, in the F77 manual: > > SUBROUTINE HANDLE_ERR(STATUS) > INTEGER STATUS > IF (STATUS .NE. NF_NOERR) THEN > PRINT *, NF_STRERROR(STATUS) > STOP ’Stopped’ > ENDIF > END > Yes, I found this (and added it to the index in all documents, to make it easier to find next time. > You see there's the status check in there already. Similar in the C > and F90 manuals. So all the error checks mentioned in the rest of the > examples in the manuals can be dropped. > I will send Russ's answer via email. > > > > > Thanks again for looking at my beta! > > > > I am also looking into the problem of the man pages and where they > > end up, but haven't > > found a solution yet. Thanks for pointing out the problem. > > Yes, I thought it would not be easy. I just wrote a Fink script that > simply copies the stuff in place after a "make install-strip". > > By the way, I noticed that "make install" does not descend into the > man/ directory to install the manuals and/or the docs. That's fine > with me, but there is no target install-man (in the main Makefile) > which should do the job. And there is no install-doc (or similar) > target that just installs (but not makes) the netcdf*.pdf manuals. > Yes, this is the very problem I noticed yesterday. Thanks, Ed Ticket Details =================== Ticket ID: IQO-210917 Department: Support netCDF Priority: Normal Status: Closed