New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Umpire incompatible with rocm 5.3.0 #800
Comments
cc @pelesh |
Tried reverting to umpire 6.0.0, our last working version, and am getting the same error as above. Tried toggling ~shared with no change in the output. v6.0.0 logs below the cutspec
|
Sorry I missed this. It looks like a system configuration problem. Your build is pulling in standard library headers from GCC 4.8.5: Umpire now requires C++14, and previously C++11, and needs a newer compiler. You may need to provide a |
Thanks for the suggestion @davidbeckingsale. I tried adding the |
I am trying to compile from source to pin down if it is a problem with Umpire or our compiler and I have attached the full error log from trying to compile with v6.0.0 and clang15.0.0. The Here is the most notable snippet from the output:
|
Modifying some of the logic from here: https://github.com/LLNL/radiuss-spack-configs/blob/main/packages/camp/package.py#L86-L112 may help. You can add the |
A couple of additional suggestions:
|
@jaelynlitz I missed the bit where you mentioned building from source, rather than Spack. You can try passing BLT_CMAKE_IMPLICIT_LINK_DIRECTORIES_EXCLUDE directly to CMake, e.g.:
|
@davidbeckingsale that worked for compiling from source! I'll see what I can do to transfer into spack |
After success compiling from source with gcc10.2.0, I have been trying to build umpire via spack with gcc10.2.0. However, Umpire is still trying to use the clang15.0.0 compiler and still linking against gcc4.8.5. The Attached spack.yaml and concretization and build output |
I was able to repro the same issues as @jaelynlitz using latest spack develop and the same box. I verified that the BLT exclude configuration was being passed to umpire, and nothing on the system path should be linked in. I also verified with This leads me to believe something funky is going on with the spack compiler wrapper and how it has gcc/clang configured. I can posted updated logs/spack configuration but they are largely the same as ones already posted in the issue. Maybe getting more information from spack would be helpful? I am a little at a loss why building by hand and through spack are giving such different results. |
Seeing as we are up to rocm/6.0.0 now and we have the CI working for rocm/5.6.0, can this be closed? |
Waiting a few more days.. if no response, I will close this issue. |
This isn't critical path for any project work since ECP came to and end, and so I don't think we are going to get to testing this anytime soon. I assume that this issue can be closed given your reports, and we can re-open any issues that we might have found with ROCm 5.6.0/6.0.0 as necessary |
Describe the bug
Hi, I'm a developer on ExaGO within ExaSGD. I'm trying to upgrade our dependency on Umpire from version 6.0.0 to 2022.3.1. I'm building Umpire via Spack within our software stack and am running into some build errors. This is an AMD system and I'm trying to use ROCm 5.3.0.
@cameronrutherford
To Reproduce
Concretize with gcc 10.2.0, rocm 5.3.0 with the options below. Try to
spack install
umpire.Expected behavior
Code to compile.
Compilers & Libraries (please complete the following information):
Additional context
Below the cut are the errors from the build log:
Logs
Spack spec: umpire@2022.03.1%gcc@10.2.0+c~cuda+device_alloc~deviceconst~examples~fortran~ipo~numa~openmp+rocm+shared amdgpu_target=gfx90a build_system=cmake build_type=RelWithDebInfo patches=78daca9 tests=none arch=linux-centos7-zen2
The text was updated successfully, but these errors were encountered: