NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Ok, thanks. So I am going to go ahead and at some point kill the upper case mod option unless I hear any objections. =Dennis Heimbigner Unidata Roy Dennington wrote:
Dennis, I double-checked the machine, and Dave was right. That particular file system is configured case-insensitive. On a case-insensitive Mac running Lion, the UPPER_CASE_MOD code needs to be inactive. The Makefile.am file I sent adds a few more tests to completely disable the UPPER case code. Does anyone on the list know of a compiler that depends on the upper case MOD mechanism? Dennis may be right about not needing the upper case MOD files. Roy -----Original Message----- From: Dennis Heimbigner [mailto:dennis.heimbigner@xxxxxxxxx] On Behalf Of Dennis Heimbigner Sent: Saturday, February 23, 2013 2:22 PM To: Roy Dennington Cc: 'Dave Allured - NOAA Affiliate'; netcdfgroup@xxxxxxxxxxxxxxxx Subject: Re: [netcdfgroup] Mac OS X with Intel Fortran compiler make error I have been pushing to drop the whole upper case MOD mechanism from the Makefile.am/configure. My assumption was that there no longer existed any fortran compilers that needed it. Does this discussion mean that my assumption was wrong for OSX? =Dennis Heimbigner Unidata Roy Dennington wrote:Dave,Thank you for the info. Your comments shed some light on the problem. I think it may be related to the special case of having a Mac OS X system that is configured "case sensitive". I think the problems are related, but the issue may be a bug in Makefile.am. Since I am not sure what is intended, perhaps a few questions about Makefile.am are inorder:[1] Is the UPPER_CASE_MOD branch intended only for systems that are case-insensitive? [2] Are the UCHEADERS mod files intended only for such systems, or are they supposed to be written on every system?In Makefile.am on my system, some of the UPPER_CASE_MOD code is commented out, and UPPER_CASE_MOD is false. I suspect that on case-sensitive systems, the resulting Makefile should not copy the mod files to upper case. I think the following block needs to be wrapped:if UPPER_CASE_MOD $(UCHEADERS): $(LCHEADERS) for lc in $(LCHEADERS) ; do \ uc="$${lc%%.mod}" ; \ uc=`echo $$uc | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`; \ uc="$${uc}.mod" ; rm -f $$uc ; cp $$lc $$uc ; \ done endif UPPER_CASE_MODThis block actually gets executed five times (without the wrap). It would seem it would be better to write individual rules for each mod file. For example,NETCDF_NC_DATA.mod: module_netcdf_nc_data.mod cp -fp module_netcdf_nc_data.mod NETCDF_NC_DATA.modI haven't tried it, so it is just a thought. I could easily be wrong. I am certainly not an expert on makefiles.One other problem. BUILT_SOURCES also needs to be wrapped: if UPPER_CASE_MODCOMMONHEADERS = $(UCHEADERS) $(UCCOMMON) BUILT_SOURCES += $(UCHEADERS) $(UCCOMMON) $(LCHEADERS) $(LCCOMMON) else !UPPER_CASE_MOD COMMONHEADERS = $(LCHEADERS) $(LCCOMMON) BUILT_SOURCES += $(LCHEADERS) $(LCCOMMON) endif !UPPER_CASE_MODBy making these changes, UCHEADERS and UCCOMMON become inactive when UPPER_CASE_MOD is false. I attached my Makefile.am. Note, I do not know under what conditions UPPER_CASE_MOD would be true, so I have no way to test.Thanks for your help, Roy -----Original Message----- From: Dave Allured - NOAA Affiliate [mailto:dave.allured@xxxxxxxx] Sent: Friday, February 22, 2013 8:02 PM To: Roy Dennington Cc: netcdfgroup@xxxxxxxxxxxxxxxxSubject: Re: [netcdfgroup] Mac OS X with Intel Fortran compiler make errorRoy,There is a persistent bug in Netcdf configure scripts through at least the current release of Netcdf-fortran 90 (4.2). This is triggered by the weird case insensitive file systems on Macs that are actually case sensitive on write. As I recall, this is technically an autotools bug, not Netcdf, though autotools code gets bundled into Netcdf distributions. The bug causes fortran module file names to become gratuitously renamed to uppercase, after the compiler generates the correct names in the first place. Now I wonder if the same problemslipped into netcdf-fortran 4.4.The code that you disabled in Makefile.am is a lowercase to uppercase file renamer, thus I think we may be discussing the same thing. The real problem may not be the renamer, but the original autotools test that makes the wrong decision in the first place. This old support thread has more details and may be of some help here:http://www.unidata.ucar.edu/mailing_lists/http://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg07755. htmlIf Unidata does not have one of these so-called case insensitive Mac file systems for testing, then they may very well have missed this thing in a recent effort to remove uppercase module file names. I have not had the time to look into this more closely. HTH.--Dave On Fri, Feb 22, 2013 at 5:00 PM, Roy Dennington <roy@xxxxxxxxxxxx> wrote:Group, Using today's netcdf-fortran trunk: svn co http://svn.unidata.ucar.edu/repos/netcdf-fortran/trunk/ glibtoolize ; aclocal ; autoheader; automake --add-missing ; autoconf ./configure \ --prefix=/home/tools/netcdf-fortran \ --enable-f03 \CPPFLAGS='-DBUILD_F03 -DNO_NETCDF_2 -DpgiFortran -I/home/tools/netcdf/include -I/home/tools/hdf5/include-I/home/tools/zlib'\LDFLAGS='-L/home/tools/netcdf/lib -L/home/tools/hdf5/lib -L/home/tools/zlib/lib' \LIBS='-lnetcdf_sc -lhdf5_hl_sc -lhdf5_sc -lz_sc' make make check I get the following error: make all-recursive Making all in fortran ifort -DHAVE_CONFIG_H -I. -I.. -I../libsrc -DBUILD_F03 -DNO_NETCDF_2-DpgiFortran -I/home/tools/netcdf/include -I/home/tools/hdf5/include -I/home/tools/zlib -g -c -o module_netcdf_nc_data.omodule_netcdf_nc_data.F90 ifort -g -c -o module_netcdf_nc_interfaces.o module_netcdf_nc_interfaces.f90 ifort -DHAVE_CONFIG_H -I. -I.. -I../libsrc -DBUILD_F03 -DNO_NETCDF_2-DpgiFortran -I/home/tools/netcdf/include -I/home/tools/hdf5/include -I/home/tools/zlib -g -c -o module_netcdf_nf_data.omodule_netcdf_nf_data.F90 ifort -DHAVE_CONFIG_H -I. -I.. -I../libsrc -DBUILD_F03 -DNO_NETCDF_2-DpgiFortran -I/home/tools/netcdf/include -I/home/tools/hdf5/include -I/home/tools/zlib -g -c -o module_netcdf_nf_interfaces.omodule_netcdf_nf_interfaces.F90 ifort -g -c -o module_netcdf_f03.o module_netcdf_f03.f90for lc in netcdf_nc_data.mod netcdf_nc_interfaces.mod netcdf_nf_data.mod netcdf_nf_interfaces.mod netcdf_f03.mod ; do \uc="${lc%%.mod}" ; \ uc=`echo $uc | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`; \ uc="${uc}.mod" ; rm -f $uc ; cp $lc $uc ; \ done cp: netcdf_nc_data.mod: No such file or directory cp: netcdf_nc_interfaces.mod: No such file or directory cp: netcdf_nf_data.mod: No such file or directory cp: netcdf_nf_interfaces.mod: No such file or directory cp: netcdf_f03.mod: No such file or directory make[2]: *** [NETCDF_NC_DATA.mod] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I am not sure why, but the .mod files are deleted after they are built. Commenting out the following lines in fortran/Makefile.am: # for lc in $(LCHEADERS) ; do \ # uc="$${lc%%.mod}" ; \ # uc=`echo $$uc | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`; \ # uc="$${uc}.mod" ; rm -f $$uc ; cp $$lc $$uc ; \ # doneI get a correct build and all tests pass. Which compiler is causing all the craziness with uppercase names?How do you control the f03 build? I added both " --enable-f03" and "-DBUILD_F03".Can I still trigger a build in libsrc with the old stuff? Are you planning to delete the libsrc code?Thanks, Roy Dennington Semichem, Inc. _______________________________________________ netcdfgroup mailing list netcdfgroup@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/--------------------------------------------------------------------- --- _______________________________________________ netcdfgroup mailing list netcdfgroup@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit:
netcdfgroup archives: