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/
