-
Notifications
You must be signed in to change notification settings - Fork 123
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
SYCL builds of UR fail due to undefined reference to std::filesystem #451
Comments
@bmyates I'd ideally like to replicate this build environment in our CI so we can catch these issues before they reach SYCL, is it documented somewhere? |
We could rip out the use of It's not reasonable to expect that UR (or any project) is bug-compatible with every compiler and standard library version. We need to have stable target platforms (e.g., whatever ships in some stable versions of RHEL, SUSE, and Debian). Also, I found this, which says that std::filesystem on GCC 8 requires adding |
The C++17 requirement is inherited from upstream LLVM, I still think its reasonable for UR to also require it. I'd like to avoid reverting to C++14 if possible as This issue is frustrating though and I'd like to avoid getting bug reports from CI pipelines I'm not aware of moving forwards.
Totally agree that we need to have a list of supported platforms, those at least need to line up with the ones in DPC++. Once we have that we can expand our CI and acceptance criteria for PRs to avoid recurrances moving forwards.
These lines in the root |
I agree, it is frustrating for me as well. I have requested a list of required platforms from SYCL but have not received an answer yet. |
I ran into this problem trying to build the SYCL compiler from the intel/llvm repository. I am using a RHEL8 system with gcc 8.3.1. It doesn't look like it's caused by a lack of C++17 |
RHEL 8 is be based on Fedora 28 and I've managed to reproduce this error there, working on a fix. |
This patch replaces changes the logic used to specify linking against `libstdc++fs.a` required to use early iterations of `std::filesystem`. Previously CMake checked for the existence of the `<filesystem>` header to enable linking the static library, however in GCC 8 this header exists while still requiring manual linking against the static library. Now we check if we are compiling with `libstdc++` and always manually link against the static library. Fixes oneapi-src#451.
This patch replaces changes the logic used to specify linking against `libstdc++fs.a` required to use early iterations of `std::filesystem`. Previously CMake checked for the existence of the `<filesystem>` header to enable linking the static library, however in GCC 8 this header exists while still requiring manual linking against the static library. Now we check if we are compiling with `libstdc++` and always manually link against the static library. Fixes oneapi-src#451.
@bmyates / @andykaylor could you please verify the fix in #456 works as expected on the fialing RHEL builds? |
Thanks @andykaylor, I'll merged the now. I've created #457 to cover adding CI to try and avoid this reoccuring in future. |
This patch replaces changes the logic used to specify linking against `libstdc++fs.a` required to use early iterations of `std::filesystem`. Previously CMake checked for the existence of the `<filesystem>` header to enable linking the static library, however in GCC 8 this header exists while still requiring manual linking against the static library. Now we check if we are compiling with `libstdc++` and always manually link against the static library. Fixes #451.
After addition in #439 some SYCL builds of UR are failing with undefined reference to std::filesystem::__cxx11::path::_M_split_cmpts()`
See this comment:: intel/llvm#9053 (comment)
The text was updated successfully, but these errors were encountered: