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 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/
