Re: [netcdfgroup] Mac OS X with Intel Fortran compiler make error

  • To: <dmh@xxxxxxxxxxxxxxxx>
  • Subject: Re: [netcdfgroup] Mac OS X with Intel Fortran compiler make error
  • From: "Roy Dennington" <roy@xxxxxxxxxxxx>
  • Date: Mon, 25 Feb 2013 10:39:04 -0600
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/ 



  • 2013 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: