September 2020 - Ecp-aurora-sdk-discuss

Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0
by Willmore, Frank Ted 29 Sep '20

29 Sep '20

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

1 0

Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0
by Whitney, Brian 29 Sep '20

29 Sep '20

The configure process for WEST was finding -loopopt=0 and not removing it from the list of things to include, so had to add that into configure to ignore -loopopt=0. Brian From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of "Whitney, Brian via Ecp-aurora-sdk-discuss" <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Reply-To: "Whitney, Brian" <brian.whitney(a)intel.com> Date: Tuesday, September 29, 2020 WW40 at 12:10 PM To: "Willmore, Frank Ted" <willmore(a)anl.gov>, ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Is this because something is generated from cmake or autoconfig? Brian From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of "Willmore, Frank Ted via Ecp-aurora-sdk-discuss" <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Reply-To: "Willmore, Frank Ted" <willmore(a)anl.gov> Date: Tuesday, September 29, 2020 WW40 at 12:05 PM To: ECP Aurora <ecp-aurora-sdk-discuss(a)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. More on the issue here: https://software.intel.com/en-us/comment/1952923#<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 willmore(a)anl.gov<mailto:[email protected]>

1 0

Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0
by Applencourt, Thomas 29 Sep '20

29 Sep '20

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(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Tuesday, September 29, 2020 14:04 To: ECP Aurora <ecp-aurora-sdk-discuss(a)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. 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 willmore(a)anl.gov<mailto:[email protected]>

1 0

Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0
by Whitney, Brian 29 Sep '20

29 Sep '20

Is this because something is generated from cmake or autoconfig? Brian From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of "Willmore, Frank Ted via Ecp-aurora-sdk-discuss" <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Reply-To: "Willmore, Frank Ted" <willmore(a)anl.gov> Date: Tuesday, September 29, 2020 WW40 at 12:05 PM To: ECP Aurora <ecp-aurora-sdk-discuss(a)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. More on the issue here: https://software.intel.com/en-us/comment/1952923#<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 willmore(a)anl.gov<mailto:[email protected]>

1 0

unfortunately named fortran compiler option -loopopt=0
by Willmore, Frank Ted 29 Sep '20

29 Sep '20

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 willmore(a)anl.gov<mailto:[email protected]>

1 0

Re: [Ecp-aurora-sdk-discuss] CMake detection of OpenMP on Iris
by Anisimov, Victor 28 Sep '20

28 Sep '20

Hi Elliot, Great that you’ve got your code compiled! You may know that Intel is replacing icc and icpc with icx and icpx, respectively in oneAPI, which are LLVM-based compilers. That said, if you want to make your software code compatible with oneAPI, you should consider switching to icx and icpx at some moment. These compilers generate perfect CPU-only code if you do not use GPU extensions. Please let us know if you need help with transitioning your code to icx and icpx compilers. Thank you, Victor -- Victor Anisimov, PhD Application Performance Engineer Argonne Leadership Computing Facility 9700 S. Cass Ave, Bldg 240, Room 1121 Lemont, IL 60439 > On Sep 28, 2020, at 5:53 PM, Slaughter, Elliott David <eslaught(a)slac.stanford.edu> wrote: > > Hi all, > > I've been able to determine that the issue was attempting to use clang/clang++ instead of icc/icpc for the OpenMP code. (This is CPU OpenMP code where I don't need it to run on the GPU.) With icc/icpc I've been able to get the code to compile. > > Thanks. > > On 9/28/20, 3:15 PM, "Anisimov, Victor" <vanisimov(a)anl.gov> wrote: > > Hi Elliot, > > Following is an example how you can check the ability of cmake to find OpenMP components. > > 1) Open an interactive session on Iris node > qsub -I -n 1 -t 60 -q iris > > 2) Load required modules: > export MODULEPATH=/soft/restricted/CNDA/modulefiles > module load oneapi > module load cmake > > 3) Create CMakeLists.txt with the following content: > cmake_minimum_required(VERSION 3.17) > project (Test C CXX Fortran) > find_package(OpenMP REQUIRED) > > 4) Run the script > mkdir build; cd build > cmake .. > > Following is what I get: > > -- The C compiler identification is Clang 12.0.0 > -- The CXX compiler identification is Clang 12.0.0 > -- The Fortran compiler identification is Intel 2019.0.0.20200827 > -- Check for working C compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icx > -- Check for working C compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icx - works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icpx > -- Check for working CXX compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icpx - works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Check for working Fortran compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx > -- Check for working Fortran compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx - works > -- Detecting Fortran compiler ABI info > -- Detecting Fortran compiler ABI info - done > -- Checking whether /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx supports Fortran 90 > -- Checking whether /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx supports Fortran 90 - yes > -- Found OpenMP_C: -fopenmp=libiomp5 (found version "5.0") > -- Found OpenMP_CXX: -fopenmp=libiomp5 (found version "5.0") > -- Found OpenMP_Fortran: -qopenmp (found version "5.0") > -- Found OpenMP: TRUE (found version "5.0") > -- Configuring done > -- Generating done > -- Build files have been written to: /home/vanisimov/cmake/test_openmp/build > > This shows that OpenMP is properly found. > > In your case, check CC, CXX, and FC values that you supply to cmake. > > Thank you, > Victor > > -- > Victor Anisimov, PhD > Application Performance Engineer > Argonne Leadership Computing Facility > 9700 S. Cass Ave, > Bldg 240, Room 1121 > Lemont, IL 60439 > >> On Sep 28, 2020, at 4:42 PM, Slaughter, Elliott David via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> wrote: >> >> Hi, >> >> Is there any trick to getting CMake to detect OpenMP on Iris? I'm getting the following: >> >> CMake Error at /soft/packaging/spack-builds/linux-rhel7-x86_64/gcc-9.3.0/cmake-3.17.0-5dgh2gvtfsxrvwqkw3m7jq2jhhk6yhph/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 (message): >> Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) >> >> The available advice online seems to indicate it can be caused by OpenMP missing. But I've done module load oneapi in my environment, so I'm confused why it can't find it. >> >> Thanks. >> >> -- >> Ecp-aurora-sdk-discuss mailing list >> Ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov >> https://lists.jlse.anl.gov/mailman/listinfo/ecp-aurora-sdk-discuss > >

1 0

Re: [Ecp-aurora-sdk-discuss] CMake detection of OpenMP on Iris
by Slaughter, Elliott David 28 Sep '20

28 Sep '20

Hi all, I've been able to determine that the issue was attempting to use clang/clang++ instead of icc/icpc for the OpenMP code. (This is CPU OpenMP code where I don't need it to run on the GPU.) With icc/icpc I've been able to get the code to compile. Thanks. On 9/28/20, 3:15 PM, "Anisimov, Victor" <vanisimov(a)anl.gov> wrote: Hi Elliot, Following is an example how you can check the ability of cmake to find OpenMP components. 1) Open an interactive session on Iris node qsub -I -n 1 -t 60 -q iris 2) Load required modules: export MODULEPATH=/soft/restricted/CNDA/modulefiles module load oneapi module load cmake 3) Create CMakeLists.txt with the following content: cmake_minimum_required(VERSION 3.17) project (Test C CXX Fortran) find_package(OpenMP REQUIRED) 4) Run the script mkdir build; cd build cmake .. Following is what I get: -- The C compiler identification is Clang 12.0.0 -- The CXX compiler identification is Clang 12.0.0 -- The Fortran compiler identification is Intel 2019.0.0.20200827 -- Check for working C compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icx -- Check for working C compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icx - works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icpx -- Check for working CXX compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icpx - works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Check for working Fortran compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx -- Check for working Fortran compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx - works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx supports Fortran 90 -- Checking whether /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx supports Fortran 90 - yes -- Found OpenMP_C: -fopenmp=libiomp5 (found version "5.0") -- Found OpenMP_CXX: -fopenmp=libiomp5 (found version "5.0") -- Found OpenMP_Fortran: -qopenmp (found version "5.0") -- Found OpenMP: TRUE (found version "5.0") -- Configuring done -- Generating done -- Build files have been written to: /home/vanisimov/cmake/test_openmp/build This shows that OpenMP is properly found. In your case, check CC, CXX, and FC values that you supply to cmake. Thank you, Victor -- Victor Anisimov, PhD Application Performance Engineer Argonne Leadership Computing Facility 9700 S. Cass Ave, Bldg 240, Room 1121 Lemont, IL 60439 > On Sep 28, 2020, at 4:42 PM, Slaughter, Elliott David via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> wrote: > > Hi, > > Is there any trick to getting CMake to detect OpenMP on Iris? I'm getting the following: > > CMake Error at /soft/packaging/spack-builds/linux-rhel7-x86_64/gcc-9.3.0/cmake-3.17.0-5dgh2gvtfsxrvwqkw3m7jq2jhhk6yhph/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 (message): > Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) > > The available advice online seems to indicate it can be caused by OpenMP missing. But I've done module load oneapi in my environment, so I'm confused why it can't find it. > > Thanks. > > -- > Ecp-aurora-sdk-discuss mailing list > Ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov > https://lists.jlse.anl.gov/mailman/listinfo/ecp-aurora-sdk-discuss

1 0

Re: [Ecp-aurora-sdk-discuss] CMake detection of OpenMP on Iris
by Anisimov, Victor 28 Sep '20

28 Sep '20

Hi Elliot, Following is an example how you can check the ability of cmake to find OpenMP components. 1) Open an interactive session on Iris node qsub -I -n 1 -t 60 -q iris 2) Load required modules: export MODULEPATH=/soft/restricted/CNDA/modulefiles module load oneapi module load cmake 3) Create CMakeLists.txt with the following content: cmake_minimum_required(VERSION 3.17) project (Test C CXX Fortran) find_package(OpenMP REQUIRED) 4) Run the script mkdir build; cd build cmake .. Following is what I get: -- The C compiler identification is Clang 12.0.0 -- The CXX compiler identification is Clang 12.0.0 -- The Fortran compiler identification is Intel 2019.0.0.20200827 -- Check for working C compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icx -- Check for working C compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icx - works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icpx -- Check for working CXX compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/icpx - works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Check for working Fortran compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx -- Check for working Fortran compiler: /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx - works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx supports Fortran 90 -- Checking whether /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx supports Fortran 90 - yes -- Found OpenMP_C: -fopenmp=libiomp5 (found version "5.0") -- Found OpenMP_CXX: -fopenmp=libiomp5 (found version "5.0") -- Found OpenMP_Fortran: -qopenmp (found version "5.0") -- Found OpenMP: TRUE (found version "5.0") -- Configuring done -- Generating done -- Build files have been written to: /home/vanisimov/cmake/test_openmp/build This shows that OpenMP is properly found. In your case, check CC, CXX, and FC values that you supply to cmake. Thank you, Victor -- Victor Anisimov, PhD Application Performance Engineer Argonne Leadership Computing Facility 9700 S. Cass Ave, Bldg 240, Room 1121 Lemont, IL 60439 > On Sep 28, 2020, at 4:42 PM, Slaughter, Elliott David via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> wrote: > > Hi, > > Is there any trick to getting CMake to detect OpenMP on Iris? I'm getting the following: > > CMake Error at /soft/packaging/spack-builds/linux-rhel7-x86_64/gcc-9.3.0/cmake-3.17.0-5dgh2gvtfsxrvwqkw3m7jq2jhhk6yhph/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 (message): > Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) > > The available advice online seems to indicate it can be caused by OpenMP missing. But I've done module load oneapi in my environment, so I'm confused why it can't find it. > > Thanks. > > -- > Ecp-aurora-sdk-discuss mailing list > Ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov > https://lists.jlse.anl.gov/mailman/listinfo/ecp-aurora-sdk-discuss

1 0

Re: [Ecp-aurora-sdk-discuss] CMake detection of OpenMP on Iris
by Bertoni, Colleen 28 Sep '20

28 Sep '20

Hello, Thanks for the report! Is it possible to send us a reproducer/point us to the code so we can try to debug? Thanks, Colleen ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Slaughter, Elliott David via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Monday, September 28, 2020 4:42 PM To: ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] CMake detection of OpenMP on Iris Hi, Is there any trick to getting CMake to detect OpenMP on Iris? I'm getting the following: CMake Error at /soft/packaging/spack-builds/linux-rhel7-x86_64/gcc-9.3.0/cmake-3.17.0-5dgh2gvtfsxrvwqkw3m7jq2jhhk6yhph/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 (message): Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) The available advice online seems to indicate it can be caused by OpenMP missing. But I've done module load oneapi in my environment, so I'm confused why it can't find it. Thanks.

1 0

CMake detection of OpenMP on Iris
by Slaughter, Elliott David 28 Sep '20

28 Sep '20

Hi, Is there any trick to getting CMake to detect OpenMP on Iris? I'm getting the following: CMake Error at /soft/packaging/spack-builds/linux-rhel7-x86_64/gcc-9.3.0/cmake-3.17.0-5dgh2gvtfsxrvwqkw3m7jq2jhhk6yhph/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 (message): Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) The available advice online seems to indicate it can be caused by OpenMP missing. But I've done module load oneapi in my environment, so I'm confused why it can't find it. Thanks.

1 0