undefined symbol in libaccp-clang.so #1459
Comments
|
Hi! The AUR packages are maintained by third parties, and not officially supported. I don't know what state they are currently in. Last time I checked, I would rate the packages as "good first effort, not for production" but maybe they have improved. The ABI issue that you see generally indicates that you are trying to load the AdaptiveCpp clang plugin into a different clang/LLVM than it was compiled for. This means that something in your AdaptiveCpp or Gromacs build process is broken. Can you please try compiling a simple test program? E.g. this one: https://github.com/AdaptiveCpp/AdaptiveCpp/blob/develop/doc/examples.md Otherwise, perhaps @al42and from the Gromacs team might have some insights as to how this error might occur in the Gromacs build process specifically. |
|
Thanks for the information! In the gromacs example though, I'm using the If the clang version it was compiled for is the problem, how do I change it? Is it some |
It does tell you that AdaptiveCpp was built against
It is true that Gromacs recommends this (and I am sure they have good reasons), however, our AdaptiveCpp documentation actually discourages this configuration and only partially supports this (also for good reasons). I'm not sure whether the reasoning for recommending building against ROCm clang applies to end users running things on a desktop system with Arch Linux as well. On an HPC cluster, software stacks and requirements can be quite different compared to an end user system. From the AdaptiveCpp point of view, you might have an easier time just building against your system clang/LLVM, which the package seems to be doing as well. You can tell AdaptiveCpp which LLVM to build against using There is also a way to override the clang that it tries to use using the |
|
It seems you are correct. I didn't consider that I tried building Gromacs with the system Thanks a lot! |
The rationale for recommending amdclang from GROMACS side is two-fold:
Other than that, there is nothing wrong with using GROMACS with mainline Clang. It is tested to work. Apparently, the AdaptiveCpp package in AUR is built against system Clang; in this case, it is reasonable to also use it for GROMACS. As I gather, this is what worked for you in the end. So, all good! |
|
Thanks for sharing your insights! One small remark:
I think this is only the case if you limit the compiler interaction with amdclang to a minimum (which generally is the case for CUDA/HIP compilation flows). As soon as you want to do something more involved with it (e.g. SSCP), it is far less predictable and generally unstable. It's true that LLVM is complex and there are lots of ways an installation can be configured. But we do how exactly it has to be built, including example cmake invocation. |
True. We're just recommending it for narrow GROMACS use case on AMD GPUs; in the NVIDIA section of the manual, we recommend mainline LLVM. I guess we need to explicitly mention that if a pre-built AdaptiveCpp is installed, then a matching Clang should be used.
It's quite predictable in not supporting SSCP at all, last time I checked :)
I've been at Cray User Group meeting a couple weeks ago, and a few site admins complained to me that installing AdaptiveCpp is already a hassle they'd very much prefer to avoid. Pretty sure that a suggestion to first build LLVM won't be appreciated (not only making sure that the suggested CMake command actually works with their environment, but also writing module files, and later being responsible for it, upgrading it when the software stack is updated, etc). For end-users: if you think a typical biophysics undergrad knows how to find the "subdirectory containing the LLVM cmake files" (or what most of those words mean), you're waaay too optimistic :) |
The example cmake invocation on https://github.com/AdaptiveCpp/AdaptiveCpp/blob/develop/doc/install-llvm.md was actually used multiple times on different Cray systems. I'm not aware of any problems that might occur there. However, I think it's true that there are some things we can do to help, especially around packaging (e.g. spack). Regarding the biophysics undergrad, I think there is a discrepancy between the target audience of AdaptiveCpp, which is developers of accelerated software, and end users of that software which then might be your undergrad student. Bridging this gap probably is where traditionally system administrators with the necessary expertise or packagers come into play. But I'm not sure this is an AdaptiveCpp-specific problem :) |
Bug summary
I'm trying to build gromacs with support for my AMD gpu with ACCP, but when CMAKE checks for a valid AdaptiveCpp/hipSYCL compiler I get the error:
My setup and how to reproduce
I'm running an up to date arch-linux system with
rocm 6.0.2-2from the arch repo and theadaptivecpp-rocm-git 24.02.0+17.r2664.20240325.37d1dcd7-1aur package installed.To build gromacs I run a script with the version (ie,
2024.2) as the argumentExpected behavior
The requested symbol should not be undefined
Optional additional diagnostic information
syclcc output:
The text was updated successfully, but these errors were encountered: