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 Ed, > > > I believe that this is correct and usual with autoconf/automake/ > > libtool packages. There is no way for me to know what optimization > > flags might work on your platform. So how can I set them? > > Actually I later noticed that the optimization flags were set > properly by configure (all -O2). I was premature here. Sorry. > However, the -g flag is automatically added to. BTW autoconf does turn on -g -O2 for any GNU C compiler automatically. It's not me! So if you don't want that you must use CPPFLAGS. > > >> 2) There is no easy way to switch off debugging (unless I do the > >> above AND specify AM_CPPFLAGS=../libsrc in calling make) > > > > You mean the -g option? That should no longer be turned on anywhere > > by default. If it is, that's a bug. Please let me know. All flags > > must be set by the user, for debugging or optimization. > > The files ncdump/Makefile.in and fortran/Makefile.in do have the > following variable set: > > AM_FLAGS = -g .....(etc)... > > This makes at least the fortran sources compile with the -g flag on, > irrespective of "configure". Thanks for pointing this out. I've removed those now and that will be in the next release. > Furthermore, "configure" sets the -g flag on all of CFLAGS, CXXFLAGS, > FFLAGS and FCFLAGS. This leads to debugging code to be installed in > all objects. > > I let that be for the time being, and used "make install-strip" to > get rid of it again. I haven't figured out to avoid that "configure" > adds the -g flags. That's something for you to figure out. > > >> 3) The manpages for Fortran 90 are missing (there is no file netcdf. > >> 3f90) > > > > Thanks for pointing this out! I never noticed that the F90 man > > pages wasn't being installed. I have fixed this for the next release. > > I saw that netcdf.3 and netcdf.3f are both made out of netcdf.m4. But > netcdf.3f90 is completely separate and does not seem to come from the > same source. Wouldn't you want to include the making of netcdf.3f90 > out of netcdf.m4? No, the fortran and C APIs are nearly identical. So we generate those from a common source. The F90 man page is totally different and exists on it's own. > > >> Furthermore, since man will only find netcdf.3f and netcdf.3f90 > >> when they are in directories man3f and man3f90, it may be wise to add > >> symbolic links man3f -> man3 and man3f90 -> man3 > > > > Sorry, I don't follow you here. Could you elaborate? > > netcdf.3, netcdf.3f, and netcdf.3f90 all end up in the directory > $prefix/share/man/man3 > > If you do "man netcdf" you always get the C manual. > To get the fortran manual, you can use "man 3f netcdf" or "man 3f90 > netcdf" for the F90 manual. > But this ONLY works when they are in a directory $prefix/share/man/ > man3f and $prefix/share/man/man3f90, respectively. > > So the installation should either make the man pages directly in the > corresponding directories, or all in man3 and make symbolic links in > $prefix/share/man: > man3f -> man3 > man3f90 -> man3 > > Does that make sense? Yes, thanks. I am looking into all this right now. I think the correct answer will be to have the man pages installed in their proper directories, and I am now trying to figure out how to do that in automake. > > Thanks for looking into this all. The installation on Mas OS X has > already immensely improved since 3.6.1! These are the only small > lingering issues with the installation, and then it will work > beautifully. > Wonderful! Ed Ticket Details =================== Ticket ID: IQO-210917 Department: Support netCDF Priority: Normal Status: Closed