Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0

22 Mar 2021

      I have verified that I can run autoconf 2.70. to generate a new configure script which runs successfully, at least for hypre.

However, for building with spack, this will require tinkering with the sources after download, as the configure script generated by autoconf 2.69 ships with the software release, or alternatively asking packagers to update to autoconf 2.70 before generating their configure script, which is a bit of an ask.

Thank you all for the helpful feedback, which helped me isolate the issue.

Cheers,

--Frank

Frank Willmore, Ph.D.
ALCF Operations
Argonne National Laboratory
[email protected]<mailto:[email protected]>

________________________________
From: Romero, Nichols A. <[email protected]>
Sent: Monday, March 22, 2021 11:43 AM
To: Willmore, Frank Ted <[email protected]>; Bertoni, Colleen <[email protected]>; Applencourt, Thomas <[email protected]>; ECP Aurora <[email protected]>
Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0

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 <[email protected]> on behalf of "Willmore, Frank Ted via Ecp-aurora-sdk-discuss" <[email protected]>
Reply-To: "Willmore, Frank Ted" <[email protected]>
Date: Thursday, March 18, 2021 at 5:35 PM
To: "Bertoni, Colleen" <[email protected]>, "Applencourt, Thomas" <[email protected]>, ECP Aurora <[email protected]>
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

[email protected]<mailto:[email protected]>

________________________________

From: Bertoni, Colleen <[email protected]>
Sent: Thursday, March 18, 2021 4:47 PM
To: Applencourt, Thomas <[email protected]>; ECP Aurora <[email protected]>; Willmore, Frank Ted <[email protected]>
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-...).

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

Thanks,

Colleen

________________________________

From: Ecp-aurora-sdk-discuss <[email protected]> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <[email protected]>
Sent: Thursday, March 18, 2021 1:00 PM
To: Applencourt, Thomas <[email protected]>; ECP Aurora <[email protected]>; Willmore, Frank Ted <[email protected]>
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#<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.