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 in
order:
>
> [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_MOD
>
> This 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.mod
>
> I 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_MOD
> COMMONHEADERS = $(UCHEADERS) $(UCCOMMON) BUILT_SOURCES += $(UCHEADERS)
> $(UCCOMMON) $(LCHEADERS) $(LCCOMMON) else !UPPER_CASE_MOD
> COMMONHEADERS = $(LCHEADERS) $(LCCOMMON) BUILT_SOURCES += $(LCHEADERS)
> $(LCCOMMON) endif !UPPER_CASE_MOD
>
> By 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@xxxxxxxxxxxxxxxx
> Subject: Re: [netcdfgroup] Mac OS X with Intel Fortran compiler make
> error
>
> Roy,
>
> 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 problem
slipped 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/support/help/MailArchives/netcdf/msg07755.
> html
>
> If 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.o
>> module_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.o
>> module_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.o
>> module_netcdf_nf_interfaces.F90
>>
>> ifort -g -c -o module_netcdf_f03.o module_netcdf_f03.f90
>>
>> for 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 ; \
>>
>> # done
>>
>>
>>
>> I 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@xxxxxxxxxxxxxxxx
>> For 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:
http://www.unidata.ucar.edu/mailing_lists/
