Fails to build with gcc 10 #212
Comments
|
Thanks @opoplawski for highlighting this, I don't think any of our systems are using gcc/gfortran 10. I'll take a look. |
|
It looks like gcc 10 hasn't yet been released? gcc.gnu.org still lists the 9.x branch as the latest stable release. I'll get gcc10 installed and play around with it, thanks for bringing this to our attention, it will be great to get ahead of this before gcc 10 is formally released! |
|
Correct. Fedora moves to the next gcc release just before it is fully supported as a major test for both :) |
|
I see now that Rawhide is the development release; I'm spinning up a VM to work on with it :) |
|
https://gcc.gnu.org/gcc-10/changes.html (see Fortran section) |
|
@musinsky Thanks for the tips. The issue exists and can be fixed by your work-around. Just export FCFLAGS="-w -fallow-argument-mismatch -O2"
export FFLAGS="-w -fallow-argument-mismatch -O2" |
|
Does anyone know a way this can be fixed without introducing flags? |
|
GCC 10.1.0 is released. This issue is appearing on macOS as well, as part of Homebrew testing: Homebrew/homebrew-core#54364 |
|
I am looking at this and discussing it internally. Out of curiosity, does NAG or any other Fortran compiler raise a warning/error re: argument mismatch, in line with gcc/gfortran? |
|
I think that short-term we will need to use these flags to compile, although I'm open to other solutions. I'll update the documentation and look at defining default flags for gfortran 10, and then we can proceed with the netCDF-Fortran release. |
… in gcc 10. For the time being, this flag is required when compiling netCDF-Fortran with gfortran 10. Added in support of #212
How are these flags passed in CMakeLists.txt for use with Visual Studio ? I'm using mingw 64, and the VS simply won't recognize them. Here's what I have in my CMakeLists.txt. |
|
@kvijaykiran which compiler are you using with visual studio for Fortran compilation? You mention you're using mingw, which is a gcc-based compiler, but you're using it integrated with Visual Studio? Can you talk about how you're doing that, a little bit? I can try to replicate it here. |
|
@WardF Sorry, I should have added more info. I was using MSYS2 MinGW-w64's gfortran to compile some Fortran code and build libraries on Windows 10. The gfortran version that comes with it is 10.1.0. I ended up seeing type mismatch errors as @opoplawski originally posted. I added the FCFLAGS and FFLAGS like @han190 indicated within the Makefile, and I was successfully able to get my code to compile and build .a libraries. However, my goal was to build these libraries using Visual Studio to generate .lib files, which are to be used in another project, but I do not have access to a native Fortran compiler (e.g., Intel Visual Fortran). I came across some documentation here (https://www.netlib.org/lapack/lawnspdf/lawn270.pdf) that it is possible to trick Visual Studio to use MinGW gfortran compiler through using I hope I was clear. Thanks for looking into this. Any help is appreciated. |
GCC10 fails to build netcdf-fortran and parallel-netcdf due to a issue common to both packages that is known to the upstream developers (at least for netcdf-fortran): Unidata/netcdf-fortran#212 NetCDF-fortran has fixed the issue in a new release as of early June 2020 (Unidata/netcdf-fortran#250) but the problem has not yet been patched in parallel-netcdf. The upgrade to netcdf-fortran v4.5.3 requires an associated update to netcdf-c.
GCC10 fails to build netcdf-fortran and parallel-netcdf due to a issue common to both packages that is known to the upstream developers (at least for netcdf-fortran): Unidata/netcdf-fortran#212 NetCDF-fortran has fixed the issue in a new release as of early June 2020 (Unidata/netcdf-fortran#250) but the problem has not yet been patched in parallel-netcdf. The latest version of netcdf-fortran (v4.5.3) requires netcdf-c >= v4.7.4 so the base netcdf-c package is also updated to the latest release.
|
Did anyone actually try the "-fallow-argument-mismatch" option? I mean, it works by turning the errors into warnings (not resolving anything), and compilation of netcdf-f v.4.5.2 with gfortran v10.1.0 will then run to the end. But the result is useless. That is, "configure" followed by "make" will not complain too much, and one can then do a "make install". But if you do a "make check" instead of just "make", it will (of course) not pass the tests. If you try to avoid the tests, and just do the "make"+"make install", and then when you try to build a code that includes netcdf-f, you will (of course) get "undefined references" in libnetcdff.so corresponding to each of the components that you were warned about (i.e. those that previously failed when errors were treated as errors V.4.5.2 works fine, by the way, with Intel ifort v.19.1.0.166 which is the latest Intel version I have tested. Oh, why didn't I switch to v.4.5.3? Because it doesn't solve it either. but configure in v.4.7.4 bails out with: So, not much luck there. |
|
|
I thought I had posted about this days ago, but apparently not. I can confirm that the test suite (or at least part of it) is failing unless I add |
|
Thanks! That did it. |
Hi, |
Hi |
|
Hi,
Here's what worked for me (I use modules):
First, build and install the NETCDF C library
Then, you are ready to build and install the NETCDF fortran library with gfortran:
NCVER=4.7.4
STAGINGAREA=/scratch/$USER/staging_area_NOBACKUP
SRCDIR=$STAGINGAREA/src/NETCDF
WORKDIR=$STAGINGAREA/wrk/
CC=gcc
module purge
module load netcdf-c/${NCVER}/netcdf4
NCDIR=/opt/netcdf-${NCVER}/${CC}-netcdf4
NFVER=4.5.2
cd $SRCDIR
tar -zxvf netcdf-fortran-${NFVER}.tar.gz
INSTALL_DIR=/opt/netcdf-fortran-${NFVER}
COMPNAM=gfortran
COMPVER=10.1.0
FC=gfortran
F77=gfortran
For compmod=ieee, debug, and fast you build and install separate libraries:
module load ${COMPNAM}/${COMPVER}/${compmod}
echo "======================================================================================="
echo "Building for" ${COMPNAM} ${COMPVER} ${compmod}
cd $WORKDIR
rm -rf $WORKDIR/netcdf-f-${NFVER}
mkdir $WORKDIR/netcdf-f-${NFVER}
cd $WORKDIR/netcdf-f-${NFVER}
NFDIR=${INSTALL_DIR}/${COMPNAM}-${COMPVER}-${compmod}
# remember the extra compiler option:
export FCFLAGS=${FCFLAGS}" -fallow-argument-mismatch"
export FFLAGS=${FCFLAGS}
FC=${FC} F77=${F77} CPPFLAGS="-I${NCDIR}/include" LIBS="-L${NCDIR}/lib -lnetcdf" ${SRCDIR}/netcdf-fortran-${NFVER}/configure --prefix=${NFDIR} --enable-static
make check
sudo make install
echo " "
echo "======================================================================================="
cheers,
Per
…________________________________
From: Habtamu Wubie Tesfaw ***@***.***>
Sent: 14 March 2021 11:04
To: Unidata/netcdf-fortran
Cc: Per Berg; Comment
Subject: Re: [Unidata/netcdf-fortran] Fails to build with gcc 10 (#212)
@musinsky<https://github.com/musinsky> Thanks for the tips. The issue exists and can be fixed by your work-around. Just ./configure with
export FCFLAGS="-w -fallow-argument-mismatch -O2"
export FFLAGS="-w -fallow-argument-mismatch -O2"
Hi
Could you elaborate it more. I just made a copy and past of the above two commands on the Terminal of Ubuntu 18.04. The problem still persists. I feel like I had to combine them with the ./configure command. but How can I do that? could you present the whole step here? Thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#212 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQOXWEMJ7OPOFMZB2FRHIXTTDSC3PANCNFSM4KKP6IGQ>.
|
|
Hi again,
Two more lines of info:
Configure needs FCFLAGS but (some of) the tests use FFLAGS so we need to export that too.
compmod=ieee, debug, and fast are just shorthand notation for the modules for strict ieee flags, debug flags and flags for speed optimization.
Sorry, that I forgot those at first.
Ciao, Per
…________________________________
From: Per Berg
Sent: 15 March 2021 08:00
To: Unidata/netcdf-fortran; Unidata/netcdf-fortran
Cc: Comment
Subject: Re: [Unidata/netcdf-fortran] Fails to build with gcc 10 (#212)
Hi,
Here's what worked for me (I use modules):
First, build and install the NETCDF C library
Then, you are ready to build and install the NETCDF fortran library with gfortran:
NCVER=4.7.4
STAGINGAREA=/scratch/$USER/staging_area_NOBACKUP
SRCDIR=$STAGINGAREA/src/NETCDF
WORKDIR=$STAGINGAREA/wrk/
CC=gcc
module purge
module load netcdf-c/${NCVER}/netcdf4
NCDIR=/opt/netcdf-${NCVER}/${CC}-netcdf4
NFVER=4.5.2
cd $SRCDIR
tar -zxvf netcdf-fortran-${NFVER}.tar.gz
INSTALL_DIR=/opt/netcdf-fortran-${NFVER}
COMPNAM=gfortran
COMPVER=10.1.0
FC=gfortran
F77=gfortran
For compmod=ieee, debug, and fast you build and install separate libraries:
module load ${COMPNAM}/${COMPVER}/${compmod}
echo "======================================================================================="
echo "Building for" ${COMPNAM} ${COMPVER} ${compmod}
cd $WORKDIR
rm -rf $WORKDIR/netcdf-f-${NFVER}
mkdir $WORKDIR/netcdf-f-${NFVER}
cd $WORKDIR/netcdf-f-${NFVER}
NFDIR=${INSTALL_DIR}/${COMPNAM}-${COMPVER}-${compmod}
# remember the extra compiler option:
export FCFLAGS=${FCFLAGS}" -fallow-argument-mismatch"
export FFLAGS=${FCFLAGS}
FC=${FC} F77=${F77} CPPFLAGS="-I${NCDIR}/include" LIBS="-L${NCDIR}/lib -lnetcdf" ${SRCDIR}/netcdf-fortran-${NFVER}/configure --prefix=${NFDIR} --enable-static
make check
sudo make install
echo " "
echo "======================================================================================="
cheers,
Per
________________________________
From: Habtamu Wubie Tesfaw ***@***.***>
Sent: 14 March 2021 11:04
To: Unidata/netcdf-fortran
Cc: Per Berg; Comment
Subject: Re: [Unidata/netcdf-fortran] Fails to build with gcc 10 (#212)
@musinsky<https://github.com/musinsky> Thanks for the tips. The issue exists and can be fixed by your work-around. Just ./configure with
export FCFLAGS="-w -fallow-argument-mismatch -O2"
export FFLAGS="-w -fallow-argument-mismatch -O2"
Hi
Could you elaborate it more. I just made a copy and past of the above two commands on the Terminal of Ubuntu 18.04. The problem still persists. I feel like I had to combine them with the ./configure command. but How can I do that? could you present the whole step here? Thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#212 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQOXWEMJ7OPOFMZB2FRHIXTTDSC3PANCNFSM4KKP6IGQ>.
|
I am sorry, I am a freshman at GCC compiler. So my platform is MacOS, and I am wondering can anyone of you show me the details of how to do this 'export' part in the terminal. |
|
Hi, @Fan142857. You don't have to any |
Thank you for your reply. But I see the release which I still don't get it. Can you show me the procedure to do that. (I'm kind of a freshman at using gcc to compile fortran and don't know much about macOS terminal language) |
ghost
mentioned this issue
- Requests hdf5+hl when using xl toolchains
Needed to resolve concretization conflict.
- Updates source hash for mpfr v4.0.2 and adds missing autoconf macros.
Additional autoconf macros are needed for v4.0.2 which are provided by the
autoconf-archive package. This commit adds a missing spack package for
autoconf-archive and fixes an outdated source hash for mpfr v4.0.2.
It might be better to simply include the autoconf-archive dependency at the
autoconf package level if other packages also need the extension macros.
- Adds missing hdf5 lib search paths to netcdf-fortran when using the XL toolchain.
When using the XL toolchain, libtool does automatically pass the necessary HDF5
library search paths needed at link time. This commit explicitly injects the
HDF5 library search paths to the LD_FLAGS when using the XL toolchain for
libtool.
- Excludes SIMD optimization arguments when using PGI toolchain.
The FFTW package attempts to apply SIMD optimization flags when building FFTW.
The flags selected are not controlled by variants to the fftw package spec.
However, when using PGI on ppc64le, unsupported flags are added to the
configuration.
This commit removes targetted optimization options when using a PGI toolchain.
However, it is likely this is only necessary on certain architectures (ppc64le?)
or OSes (RHEL7?) and the logic should be improved before pushing this change to
upstream spack.
- Fixes global allocation error in newer GCC.
Newer GCC (9.0+) does not quietly handle allocation for uninitialized
global variables. GDBM up to the current version requires the `-fcommon`
flag for these toolchains to overcome "multiple-definition" errors.
Unfortunately, this carries a speed and code size penalty. Perhaps GDBM
will release a newer version that corrects this problem for newer GCC
toolchains.
- Adds missing dependnency.
Imagemagick depends on libSM and, if left implicit, will generally find
libSM from the OS which is unlikely to contain libuuid symbols matching
those used when spack builds libuuid. This causes build-time missing
symbol errors. By having spack build both libuuid and libSM, the problem
is avoided and the builds are decoupled from the host OS.
- Patches broken pre-built docs out of build
The RDMA-Core releases ship with pre-built documentation in case pandoc
and rst2man are not available on the system. It is not possible to
disable documentation at configuration time and the build will fail if
documentation cannot be built or installed. However, the pre-build
documentation is not complete (at least for infiniband-diags) and
rdma-core's CMake install process will attempt to copy pre-built
documentation that does not exist at install time, causing a fatal
error.
Adding a dependency on pandoc makes the DAG for this package extremely
large (pulling in many X11 dependencies). This is bound to cause
problems for non-GCC toolchains. So rather than have the spack package
build the docs from source, we will rely on the pre-built documentation
but exclude the attempted installation of the missing infiniband-diags
man pages.
- Adds patch for intel and long directory paths.
Intel toolchains do not tolerate string array intial values larger than the declared size of the array.
The path set via `buildlib/config.h.in` for `#define ACM_CONF_DIR "@CMAKE_INSTALL_FULL_SYSCONFDIR@/rdma"` can be exceptionally long under spack. For example, in file `ibacm/prov/acmp/src/acmp.c`, the line (274) `static char route_data_file[128] = ACM_CONF_DIR "/ibacm_route.data";` sets a string 134+ characters long (ie `len("/sw/andes/spack-envs/base/opt/linux-rhel8-x86_64/clang-9.0.1/rdma-core-28.0-2ixcucck7eb4fzbd3t6imjrhz5qahxui/etc/rdma/ibacm_route.data")`).
This causes the intel compilers to choke when trying to shove that string into a 128-character array.
This commit adds a patch to the source code to allow for a path up to 192 characters in length.
It is unknown if this change breaks other things and this bug should be reported upstream.
- Adds OpenBLAS version 0.3.10
This latest version includes fixes for Zen2 targets and truncated symbol
names when using AOCC and Flang.
- Adds missing PIC flag for MPI builds with PGI.
PGI doesn't automatically propagate the PIC flag when building with MPI
support and autoconf does not detect the appropriate PIC flag when using
the mpif90 spack wrapper.
This commit forces FCFLAGS (respected by the mpif90 wrapper) to contain
the appropriate PIC flag when building with that option and MPI support
for all compilers.
- Updates NetCDF-Fortran version; adds GCC10 build error fix.
GCC10 fails to build netcdf-fortran and parallel-netcdf due to a
issue common to both packages that is known to the upstream developers
(at least for netcdf-fortran):
Unidata/netcdf-fortran#212
NetCDF-fortran has fixed the issue in a new release as of early June 2020
(Unidata/netcdf-fortran#250) but the problem has
not yet been patched in parallel-netcdf.
The latest version of netcdf-fortran (v4.5.3) requires netcdf-c >=
v4.7.4 so the base netcdf-c package is also updated to the latest
release.
- Updates Gromacs version; fixes package errors.
- Updates pkgconf dependency name.
The name of the package pkgconfig has been changed to pkgconf. This
package is updated to use the new name when declaring dependencies.
- Allow libs to be found in lib64 subdir.
When using external OpenSSL, the libs are not always in `$prefix/lib` in
the external build. Sometimes, the libraries exist in `$prefix/lib64`.
Packages which must declare the location of the SSL libraries outside of
using pkgconfig need the `openssl.libs` method to return valid paths.
- Pass OpenSSL libs via envvar without relying on pkgconfig.
When using external OS-provided OpenSSL, spack-built pkgconfig might not
be able to find the openssl libs if `/usr/lib64/pkgconfig` is not in
pkgconfig's search path. Passing the location of the OpenSSL libs
directly will work for both spack-built and external OpenSSL pacakges.
- Adds CUDA v11.0.2
The CUDA Toolkit v11.0.2, also referred to in documentation as CUDA Toolkit v11.0.194, was released on 8 July 2020 ([Release Notes](https://docs.nvidia.com/cuda/archive/11.0/)).
This commit adds this current latest version to the CUDA spack package.
- Adds fontconfig v2.13.92
This version fixes a bug that prevents fc cache updates when fonts are
missing their fc checksum files.
- Patches netlib-scalapack to solve confusion between PGI and Intel.
The netlib-scalapack CMakeLists have a faulty check to identify if the
Intel compiler suite is being used. It checks if the substring 'ifort'
matches the fortran compiler binary. Unfortunately, this also catches
the PGI fortran compiler 'pgifort'. This causes the build system to
inject Intel-specific compiler options into the build. Since
unrecognized arguments are generally fatal to PGI, this causes problems
when trying to build the package with PGI.
Instead, the developers probably want to check the
`CMAKE_Fortran_COMPILER_ID` for `Intel` which is unique for the Intel
toolchain. This commit adds a patch for this to spack builds. This patch
should probably be generalized better for future versions and applied as
a patch function. Or, better yet, contributed to the upstream Scalapack
codebase.
- Enable UCX dev headers by default.
No reason to not have the development headers available for applications
that need them.
- LSF systems must use own PMIx implementation.
IBM's PMIx libraries are not provided with LSF and instead are
incorporated in CSM or SMPI. OMPI cannot reliably find the necessary
external PMIx implementation when on certain systems using LSF.
Therefore, we force the use of internal PMIx when using LSF.
However, the LSF libdirs options are also not reliably found due to the
way IBM packages LSF headers and libraries in separate locations. The
second block of code in this commit is experimental and doesn't
necessarily work.
- Skip patching missing config files.
The libiberty subdirectory does not contain its own config files and
Spack should not attempt to patch them.
- Adds new Plumed version and library fix.
Adds latest release v2.6.2 of plumed to the spack package and ensures
that both c and fortan blas libraries are added to compiler linking
incantations.
- Fixes __ieee128 error building Gromacs on ppc64le
Proper fix may need to be done at upstream library--either NetCDF or PnetCDF. See Unidata/netcdf-fortran#212
gcc 10 has landed in Fedora Rawhide. gfortran 10 now enforces type matching in at least some function calls. netcdf-fortran 4.5.2 fails with:
The text was updated successfully, but these errors were encountered: