ifx (2021.1-beta04) HPC Toolkit build error with -loopopt

[Rashawn_K_Intel1]

Hello,

The PI of an HPC tool, Score-P, contacted me earlier today regarding an error discovered in the most recent beta of the HPC Toolkit with the Fortran compiler. The issue appears to be a conflict between Autoconf and the -loopopt option supplied to configure where the the -l is interpreted as a cue to link with the library oopopt.  The full description of the text the PI sent to me regarding the error is enclosed below. I downloaded the reproducer pointed to towards end of message, and I ran it using ifx with the Beta 04,  and I encounter the same issue with -loopopt. The team is in Europe, and I do not know the specifics of their machine, but it is certainly Linux:

I just tried your new beta compilers in the context of Score-P. I ran into a problem with the Fortran compiler and autoconf, which I will describe below. Would it be possible for you to forward this report to the compiler developers? 

Here the problem description:
ifx (2021.1-beta04) fails on autoconf (2.69) macros AC_F77_WRAPPERS/AC_FC_WRAPPERS [1] due to xfortcom's default option '-loopopt=0'

The command 

ifx -o conftest -g -v conftest.f'

calls 

/opt/intel/inteloneapi/compiler/2021.1-beta04/linux/bin/xfortcom    -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all "-verify nomodule" -main-file-name conftest.f -target-cpu x86-64 -target-linker-version 2.30 -debug-info-kind=limited -dwarf-version=4 -mllvm -debug-line-version=2 -dwarf-column-info -D__unix__ -D__unix -D__linux__ -D__linux -D__gnu_linux__ -Dunix -Dlinux -D__ELF__ -D__x86_64 -D__x86_64__ -D__amd64 -D__amd64__ -D__INTEL_COMPILER_BUILD_DATE=20200118 -I/opt/intel/inteloneapi/tbb/2021.1-beta04/env/../include -I/opt/intel/inteloneapi/mpi/2021.1-beta04//include -I/opt/intel/inteloneapi/compiler/2021.1-beta04/linux/include -I/opt/intel/inteloneapi/compiler/2021.1-beta04/linux/compiler/include/intel64 -I/opt/intel/inteloneapi/compiler/2021.1-beta04/linux/compiler/include -I/usr/local/include -I/usr/include -I/usr/include/x86_64-linux-gnu -O0 -fveclib=SVML -fno-inline -fno-inline-functions -mllvm -loopopt=0 -mllvm -enable-lv -mllvm -disable-hir-generate-mkl-call -mllvm -intel-libirc-allowed -o /tmp/ifxWAvMeA.o -D__INTEL_COMPILER=201900 -D__INTEL_COMPILER_UPDATE=0 -D__unix__ -D__unix -D__linux__ -D__linux -D__gnu_linux__ -Dunix -Dlinux -D__ELF__ -D__x86_64 -D__x86_64__ -D__amd64 -D__amd64__ -D__INTEL_COMPILER_BUILD_DATE=20200118 -I. -I/opt/intel/inteloneapi/tbb/2021.1-beta04/env/../include -I/opt/intel/inteloneapi/mpi/2021.1-beta04//include -I/opt/intel/inteloneapi/compiler/2021.1-beta04/linux/include -I/opt/intel/inteloneapi/compiler/2021.1-beta04/linux/compiler/include/intel64 -I/opt/intel/inteloneapi/compiler/2021.1-beta04/linux/compiler/include -I/usr/local/include -I/usr/include -I/usr/include/x86_64-linux-gnu "-fp_modbits honor_f32_conversion" "-fp_modbits honor_f64_conversion" -O0 -g2 "-reentrancy threaded" -simd -offload_host conftest.f


Note the '-loopopt=0'. AC_F77_WRAPPERS/AC_FC_WRAPPERS identify this option as a library:

checking for Fortran libraries of ifx...  -loopopt=0 -L/opt/intel/inteloneapi/tbb/2021.1-beta04/env/../lib/intel64/gcc4.8 -L/opt/intel/inteloneapi/mpi/2021.1-beta04//libfabric/lib -L/opt/intel/inteloneapi/mpi/2021.1-beta04//lib/release -L/opt/intel/inteloneapi/mpi/2021.1-beta04//lib -L/opt/intel/inteloneapi/compiler/2021.1-beta04/linux/lib -L/opt/intel/inteloneapi/compiler/2021.1-beta04/linux/compiler/lib/intel64_lin -L/opt/intel/inteloneapi/mpi/2021.1-beta04//libfabric/lib/../lib/ -L/opt/intel/inteloneapi/mpi/2021.1-beta04//lib/../lib/ -L/opt/intel/inteloneapi/compiler/2021.1-beta04/linux/lib/../lib/ -L/usr/lib/gcc/x86_64-linux-gnu/7/ -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/ -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/ -L/lib/x86_64-linux-gnu/ -L/lib/../lib64 -L/lib/../lib/ -L/usr/lib/x86_64-linux-gnu/ -L/usr/lib/../lib/ -L/opt/intel/inteloneapi/tbb/2021.1-beta04/env/../lib/intel64/gcc4.8/ -L/opt/intel/inteloneapi/mpi/2021.1-beta04//libfabric/lib/ -L/opt/intel/inteloneapi/mpi/2021.1-beta04//lib/release/ -L/opt/intel/inteloneapi/mpi/2021.1-beta04//lib/ -L/opt/intel/inteloneapi/compiler/2021.1-beta04/linux/lib/ -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../ -L/lib64 -L/lib/ -L/usr/lib -lifport -lifcoremt -limf -lsvml -lm -lipgo -lirc -lpthread -lirc_s -ldl

When using these Fortran libraries in icx invocations the linker complains:

ld: cannot find -loopopt=0

Note that everything works fine with the 'old' ifort, also provided by the oneAPI package.

Would it be possible to rename '-loopopt' such that it doesn't start with '-l'? '-loopopt' seems to be a non-public option, at least it is not documented in 'ifx -help'. Thus renaming might cause no harm.

Please find a minimal reproducer until 2020-02-27 here: https://gigamove.rz.rwth-aachen.de/d/id/75hs9S9jCCLR2Y

Use like this:
tar xf loopopt.tar.gz
mkdir loopopt/_build
cd  loopopt/_build
../configure CC=icx FC=ifx F77=ifx

Your advice will be appreciated, and I will relay it to the development team and also let them know about this forum.

Best regards,

Rashawn Knapp

[Steve_Lionel]

-loopopt is not an Intel Fortran option. It would indeed be interpreted as a library specification. I have no idea what -loopopt is supposed to do.

Ah, but I see this is an attempt to use OneAPI.  I am not familiar with the tools for that, though I would be puzzled if -loopopt was supposed to be a valid option there.

[Rashawn_K_Intel1]

Steve,

Thank you for your response. I thought I was filing this in the correct space. I will pop up back to the oneAPI HPCToolkit basic forum and see if someone there knows about this in the 2021.1-beta04 release.

Regards,

-Rashawn

[Feld__Christian]

Steve Lionel (Ret.) (Blackbelt) wrote:

-loopopt is not an Intel Fortran option. It would indeed be interpreted as a library specification. I have no idea what -loopopt is supposed to do.

Ah, but I see this is an attempt to use OneAPI.  I am not familiar with the tools for that, though I would be puzzled if -loopopt was supposed to be a valid option there.

You are right, -loopopt is neither an ifort nor an ifx option. But the new ifx Fortran compiler passes this option to xfortcom, which you can see if you invoke ifx in verbose mode:

$ ifx -o hello_world -g -v hello_world.f

The xfortcom command line is parsed by configure. configure collects library options and ignores other options. As -loopopt=0 starts with a -l, it is erroneously detected as library option. Subsequent linking with the detected options fails.

In case of the 'old' ifort, fortcom is called instead of xfortcom. Here, everything works as expected.

[Barbara_P_Intel]

This is the right place to post questions about the Fortran compiler that is available as part of oneAPI (beta).

Since the user is using configure to set up the environment, please specify ifort as the Fortran compiler.

Using ifx to launch the Intel Fortran Nextgen compiler is discouraged.  We are working to correct the documentation. 

The rule of thumb today for oneAPI is to use "ifort" to compile Fortran applications. That is equivalent to using the Parallel Studio version of ifort.

If you are interested in using the Fortran NextGen compiler that includes the ability to offload compute kernels to an Intel GPU, invoke the Fortran compiler using "ifort -qnextgen". 

[Barbara_P_Intel]

Thank you, Christian, for the great analysis as to why conftest.f  fails to compile.  I'll check with the compiler developers.

[Feld__Christian]

Barbara P (Intel) wrote:

Using ifx to launch the Intel Fortran Nextgen compiler is discouraged.  We are working to correct the documentation. 

Can I assume that the use of icx and icpx is also discouraged?

[Barbara_P_Intel]

Yes.  Please use "icc -qnextgen" and "icpc -qnextgen".

[Feld__Christian]

The problem persists if I switch form 'ifx' to 'ifort -qnextgen', i.e.

configure CC=icx FC=ifx F77=ifx

vs.

configure CC="icc -qnextgen" FC="ifort -qnextgen" F77="ifort -qnextgen"

Renaming -llopopt to e.g., -qloopopt fixes the problem. Please see also my comment in oneAPI HPC Toolkit forum:
https://software.intel.com/en-us/forums/intel-oneapi-hpc-toolkit/topic/848821#comment-1952922

[William_D_Intel]

A patch has been made to autoconf to address this issue.  A version of autoconf built on commit ae26b9b4 (made on 22-July-2020) or later should work.  This patch is expected to be in autoconf 2.70, which is currently in beta testing and expected be released in the next three months.

Bill.

[William_D_Intel · Accepted solution]

Autoconf 2.70 was released today (see https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg00001.html for details).  Updating to autoconf 2.70 fixes the “-loopopt=0” issue described in this discussion.

Bill.

[Dave_Allured]

This problem is still cropping up two years later.

https://forum.hdfgroup.org/t/error-when-running-configure-during-install-of-hdf5-missing-dummy-main/10477/8

Could Intel please tell us which versions of OneAPI are susceptible to the “-loopopt=0” problem with older Autoconf versions?  Facing some pushback on Autoconf, I would love to be able to advise simply, "Upgrade your OneAPI version".

[William_D_Intel]

Which version of Autoconf are you using?  It should be fixed in version 2.70, which was released 08-Dec-2020.

The underlying issue was that Autoconf tries to dig through the internal interface between the compiler driver and the Fortran compiler to figure out what libraries need to be used during linking.  Before Autoconf 2.70, Autoconf interprets a flag intended for the compiler as a the name of a library that does not exist, and so linking fails.  The fix in 2.70 was to recognize and ignore flags the compiler driver is passing to the internal Fortran compiler interface.

[Dave_Allured]

William, I am afraid I did not explain my question very well.  I am trying to refine a more general and user friendly solution for this problem.  I am not doing any installation myself.  I do well understand the underlying issue as a misinterpreted compiler option, having rediscovered it myself.

Autotools upgrade was rejected by another software developer because of broader compatibility concerns.

https://forum.hdfgroup.org/t/error-when-running-configure-during-install-of-hdf5-missing-dummy-main/...

I have this notion that a viable alternate solution could be to switch to a different OneAPI version.  Perhaps I am wrong.  I would like to find out if this conflict with older Autoconf is limited to only the single OneAPI beta04 version, or if it is more widespread.

So back to my question.  Can you tell us which versions of OneAPI are susceptible to the “-loopopt=0” problem with older Autoconf versions?

[William_D_Intel]

Dave,  ifx continues to pass "-mllvm -loopopt=n" to xfortcom.  As far as I know, all versions are affected.

[dkokron]

Another data point.  Building ESMF-8.3.1 on an Ubuntu-22.04 system results in the following error.

mpicxx -pthread -shared -qopenmp -o /home/USER/Projects/NCEP/UFS/hpc-stack/pkg/ESMF_8_3_1/lib/libO/Linux.intel.64.openmpi.default/libesmftrace_preload.so preload.o preload_io.o preload_mpi.o wrappers.o wrappers_io.o wrappers_mpi.o -m64 -mcmodel=small -pthread -Wl,--no-as-needed -qopenmp -L/home/USER/opt/intel-2023.0.0/hdf5/1.10.6/lib -L/home/USER/opt/intel-2023.0.0/zlib/1.2.11/lib -L/home/USER/Projects/NCEP/UFS/hpc-stack/pkg/ESMF_8_3_1/lib/libO/Linux.intel.64.openmpi.default -L/home/USER/opt/intel-2023.0.0/netcdf/4.7.4/lib -L/opt/intel/oneapi/compiler/2023.0.0/linux/compiler/lib/intel64_lin/ -Wl,-rpath,/home/USER/Projects/NCEP/UFS/hpc-stack/pkg/ESMF_8_3_1/lib/libO/Linux.intel.64.openmpi.default -Wl,-rpath,/home/USER/opt/intel-2023.0.0/netcdf/4.7.4/lib -Wl,-rpath,/opt/intel/oneapi/compiler/2023.0.0/linux/compiler/lib/intel64_lin/ -loopopt=1 -lifport -lifcoremt -limf -lsvml -lm -lipgo -liomp5 -lintlc -lpthread -lsvml -ldl -lgcc -lgcc_s -lirc_s -ldl -lrt -ldl -lnetcdff -lnetcdf -lhdf5_hl -lhdf5 -lz -ldl -lm -lpioc
/usr/bin/ld: cannot find -loopopt=1: No such file or directory
icpx: error: linker command failed with exit code 1 (use -v to see invocation)

autoconf --version
autoconf (GNU Autoconf) 2.71

mpicxx -V
Intel(R) oneAPI DPC++/C++ Compiler for applications running on Intel(R) 64, Version 2023.0.0 Build 20221201

GNU ld (GNU Binutils for Ubuntu) 2.38

HDF5-1_10_6 also fails during the configure phase

configure:7507: mpicc -o conftest -fPIC -w conftest.c -L/home/dkokron/play/OpenMPI/openmpi-4.1.4/install/OneAPI/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi -loopopt=1 -L/opt/intel/oneapi/mkl/2023.0.0/lib/intel64 -L/opt/intel/oneapi/tbb/2021.8.0/lib/intel64/gcc4.8 -L/opt/intel/oneapi/compiler/2023.0.0/linux/lib -L/opt/intel/oneapi/compiler/2023.0.0/linux/compiler/lib/intel64_lin -L/opt/intel/oneapi/compiler/2023.0.0/linux/lib/clang/16.0.0/lib/linux -L/home/USER/play/OpenMPI/openmpi-4.1.4/install/OneAPI/lib/../lib/ -L/opt/intel/oneapi/compiler/2023.0.0/linux/lib/../lib/ -L/usr/lib/gcc/x86_64-linux-gnu/11/ -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/ -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib64 -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib/ -L/lib/x86_64-linux-gnu/ -L/lib/../lib64 -L/lib/../lib/ -L/usr/lib/x86_64-linux-gnu/ -L/usr/lib/../lib64 -L/usr/lib/../lib/ -L/home/USER/play/OpenMPI/openmpi-4.1.4/install/OneAPI/lib/ -L/opt/intel/oneapi/mkl/2023.0.0/lib/intel64/ -L/opt/intel/oneapi/tbb/2021.8.0/lib/intel64/gcc4.8/ -L/opt/intel/oneapi/compiler/2023.0.0/linux/lib/ -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../ -L/lib64 -L/lib/ -L/usr/lib64 -L/usr/lib -L/usr/lib/i386-linux-gnu -lifport -lifcoremt -limf -lsvml -lm -lipgo -lirc -lpthread -lirc_s -ldl >&5
/usr/bin/ld: cannot find -loopopt=1: No such file or directory
icx: error: linker command failed with exit code 1 (use -v to see invocation)

icx -V
Intel(R) oneAPI DPC++/C++ Compiler for applications running on Intel(R) 64, Version 2023.0.0 Build 20221201

[Barbara_P_Intel]

Check the Fortran Release Notes. There is a workaround for this configure issue until the developer of HDF5 updates to a newer version.

I helped another customer use the workaround to build HDF5 with ifx. 

[dkokron]

reconstructing the HDF5 configure script as outlined in the release notes does resolve that configure failure.  I will contact the ESMF developers to see if they have a workaround for this.  Many thanks!