Hi-- I'm running into this same issue again. HDF5 will not configure because compilation is misinterpreting a flag: /soft/restricted/CNDA/mpich/drop39.1/mpich-ofi-sockets-icc-debug-gen9-drop39/bin/mpicc -o conftest -fPIC conftes t.c -loopopt=0 ... The culprit here is -loopopt, which is intended, presumably, for the compiler, but which is being passed to the linker which thinks it should link libloopopt (which isn't a thing). I had previously been able to work around this by using ifort instead of ifx, but ifort is no longer part of the distribution. Also, I can no longer view the discussion on the intel site at https://software.intel.com/en-us/comment/1952923# * Has there been any activity on this issue? * Is this an issue that HDF5 and the other packages who include this option need to deal with individually in their build systems? * What is the intent of this option, will it continue to exist, and is there an alternative? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory [email protected]<mailto:[email protected]> ________________________________ From: Ecp-aurora-sdk-discuss <[email protected]> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <[email protected]> Sent: Tuesday, September 29, 2020 4:31 PM To: Applencourt, Thomas <[email protected]>; ECP Aurora <[email protected]> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Thank you for replying, Thomas and Brian. I tried adding the --best-effort flag, but ifx didn't understand it. Realizing there's an ifort executable available from the oneapi module, I pointed to that and was able to configure and build hypre with that. I'm driving this from spack, and am including the compiler stanza I used below, if anyone is interested. I hacked up my own version of the oneapi module which points to pure opensuse builds of gcc, etc. since spack refuses to cross-compile to a different OS. It's an ugly hack, but I can share if anyone is interested. - compiler: spec: [email protected] paths: cc: icx cxx: icpx f77: ifort fc: ifort operating_system: opensuse_leap15 target: x86_64 modules: - /home/willmore/modulefiles/intel-oneapi/hacked environment: prepend_path: LD_LIBRARY_PATH: /home/willmore/lib:/soft/restricted/CNDA/sdk/2020.7.30.1/oneapi/compiler/2021.1-beta08/linux/compiler/lib/intel64_lin unset: [] extra_rpaths: [] Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory [email protected]<mailto:[email protected]> ________________________________ From: Applencourt, Thomas <[email protected]> Sent: Tuesday, September 29, 2020 2:15 PM To: ECP Aurora <[email protected]>; Willmore, Frank Ted <[email protected]> Subject: Re: unfortunately named fortran compiler option -loopopt=0 Hi Frank,

Would falling back to an older ifort version to build Fortran components be a reasonable option?

This is not an `official remand way` just a workaround we implemented, but you can try to add `--best-effort` flags with `ifx`. It will fall back to `ifort` if something goes wrong. So maybe it can help you when waiting for an official fix. Thomas Applencourt Leadership Computing Facility Argonne National Laboratory Building 240 Office - 1.D.18 9700 S Cass Av., Lemont Il, 60439 (630) 252-0036 ________________________________ From: Ecp-aurora-sdk-discuss <[email protected]> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <[email protected]> Sent: Tuesday, September 29, 2020 14:04 To: ECP Aurora <[email protected]> Subject: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Hi-- I've been bumping against a known issue with ifx, namely that ifx generates a flag "-loopopt=0" which is intended to be consumed by an internal component (xfortcom) but which causes ld to erroneously try to link liboopopt=0 instead, and thus causing configure to fail. I'm attempting to build hypre. More on the issue here: https://software.intel.com/en-us/comment/1952923# When I configure, I get (among other things): /usr/bin/ld: cannot find -loopopt=0 error: linking to Fortran libraries from C fails Has anyone else here stumbled on this when compiling Fortran, and if so, how did you work around it? Would falling back to an older ifort version to build Fortran components be a reasonable option? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory [email protected]<mailto:[email protected]>