[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #PEG-669046]: Unable to test Fortran wrapper compiled with Portland Fortran 15.1

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.


  • Subject: [netCDF #PEG-669046]: Unable to test Fortran wrapper compiled with Portland Fortran 15.1
  • Date: Wed, 25 Feb 2015 08:35:58 -0700

Hi Mattew,

> I have recently gained access to v15.1 of Portland Fortran and
> have been compiling up our software stack with it. Unfortunately
> the Fortran wrapper for NetCDF fails to pass its own self-test.
> Or rather it fails to build its own tests.
> 
> The failure is an inability to link "tst03_f77_v2" to "Tests_".
> This message 
> <https://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg12845.html>
> appears to refer to the same problem. However the "don't compile
> the v2 API" solution doesn't work for me as ESMF requires the
> global error variable provided by it.
> 
> The Makefile which builds the test states: "This fails with
> pgifortran, but works with gfortran." which isn't particularly
> helpful. Luckily 5 minutes work shows that if you make the
> following change it works:
> 
> am__f03tst_vars2_SOURCES_DIST = module_tests.F90 f03tst_vars2.F \
> f03lib_f_interfaces.f90 f03lib.c handle_err.F
> <<< am_f03tst_vars2_OBJECTS = \
> >>> am_f03tst_vars2_OBJECTS = module_tests.$(OBJEXT) \
> f03tst_vars2.$(OBJEXT) \
> f03lib_f_interfaces.$(OBJEXT) \
> f03lib.$(OBJEXT) handle_err.$(OBJEXT)
> f03tst_vars2_OBJECTS = $(am_f03tst_vars2_OBJECTS)
> 
> I hope this is useful to you.

Thanks, we'll fix that for the next release. Evidently, the file you are 
modifying
is nf03_test/Makefile.in, but that file is generated automatically from by the
automake tool from the Makefile.am file in the same directory, so that change
won't work for us, but we'll figure out the analogous fix to Makefile.am.

--Russ

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: PEG-669046
Department: Support netCDF
Priority: Normal
Status: Closed