Frank,

Sorry for not replying sooner. We had this problem with part of MCT (Fortran) which is part of E3SM.

You might find the discussion here helpful.

https://github.com/MCSclimate/MCT/pull/61

https://github.com/MCSclimate/MCT/pull/66

It does look like updating to autoconf 2.7 solved the issue for us.

From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces@lists.jlse.anl.gov> on behalf of "Willmore, Frank Ted via Ecp-aurora-sdk-discuss" <ecp-aurora-sdk-discuss@lists.jlse.anl.gov>
Reply-To: "Willmore, Frank Ted" <willmore@anl.gov>
Date: Thursday, March 18, 2021 at 5:35 PM
To: "Bertoni, Colleen" <bertoni@anl.gov>, "Applencourt, Thomas" <tapplencourt@anl.gov>, ECP Aurora <ecp-aurora-sdk-discuss@lists.jlse.anl.gov>
Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0

Looking at the discussion, this make sense now. I'm trying to get spack to concretize with the 2.70 version, but it looks like it will need to rebuild a whole cascade of dependents. Also, for some reason, spack keeps re-writing 2.70 as 2.7.

I'll try the 2.70 version and if it works, then it should be fine, otherwise I can work to define a reproducer.

Thanks for looking at it!

--Frank

Frank Willmore, Ph.D.

ALCF Operations

Argonne National Laboratory

willmore@anl.gov

From: Bertoni, Colleen <bertoni@anl.gov>
Sent: Thursday, March 18, 2021 4:47 PM
To: Applencourt, Thomas <tapplencourt@anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss@lists.jlse.anl.gov>; Willmore, Frank Ted <willmore@anl.gov>
Subject: Re: unfortunately named fortran compiler option -loopopt=0

Hi Frank,

Yeah, I remember this discussion for Fortran before (https://community.intel.com/t5/Intel-Fortran-Compiler/ifx-2021-1-beta04-HPC-Toolkit-build-error-with-loopopt/m-p/1235375#M153121).

This looks like C, though. Is it possible for you to send steps to reproduce?

Thanks,

Colleen

From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces@lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss@lists.jlse.anl.gov>
Sent: Thursday, March 18, 2021 1:00 PM
To: Applencourt, Thomas <tapplencourt@anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss@lists.jlse.anl.gov>; Willmore, Frank Ted <willmore@anl.gov>
Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0

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

willmore@anl.gov

From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces@lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss@lists.jlse.anl.gov>
Sent: Tuesday, September 29, 2020 4:31 PM
To: Applencourt, Thomas <tapplencourt@anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss@lists.jlse.anl.gov>
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: intel@2020.09.15.001

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

willmore@anl.gov

From: Applencourt, Thomas <tapplencourt@anl.gov>
Sent: Tuesday, September 29, 2020 2:15 PM
To: ECP Aurora <ecp-aurora-sdk-discuss@lists.jlse.anl.gov>; Willmore, Frank Ted <willmore@anl.gov>
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 <ecp-aurora-sdk-discuss-bounces@lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss@lists.jlse.anl.gov>
Sent: Tuesday, September 29, 2020 14:04
To: ECP Aurora <ecp-aurora-sdk-discuss@lists.jlse.anl.gov>
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.