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/
