build failure on gcc 11.1 #260
Comments
|
Can you build verbose so that you can share the compile command? The CMake script sets the C++ standard to 14, so I'm curious whether it's ending up passing a command line arg at all. |
|
An issue (number 1571) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#1571 ), to facilitate working group processes. This GitHub issue will continue to be the main site of discussion. |
|
Right, here is one full output with ninja --verbose I see a bunch of -std=gnu++14 but if I see it correctly, no -std= at the step 64/68 that fails. |
|
Thank you so much for the workaround! I expected having to file an issue myself, and maybe even fix it myself, but your fix made everything work immediately! |
|
I am getting a very similar error to this I believe. But it looks like the CMake file has changed and your patch doesn't some seem to fix it anymore. I am trying to build on the latest archlinux. |
|
Yeah, the patch is unfortunately not a solution we can upstream. Are folks who are trying this starting with a clean build directory? If https://github.com/KhronosGroup/OpenXR-SDK-Source/blob/master/src/cmake/StdFilesystemFlags.cmake ran and determined one way to get stdc++fs, then the compiler is upgraded, that would explain what we're seeing. Otherwise https://github.com/KhronosGroup/OpenXR-SDK-Source/blob/master/src/cmake/StdFilesystemFlags.cmake is somehow failing to correctly detect how to link that. |
|
I am doing the build from a fresh clone, also a fresh install of manjaro. I've trying to build the non 'Source' version of this. But they look to have the same exact cmake setup, so it should be the same issue. I did install this package: Is there some other dependency that this could rest on which maybe I am missing? |
|
building with clang works like a charm, but would be nice to figure out issue with gcc |
|
I'm reasonably certain you shouldn't need libstdc++5, I think that's for really old binaries. The CMake is just not properly detecting on Arch or Manjaro whether it needs to add stdc++fs to the link line. @ChristophHaag is probably in the best position to help here since I work with him and he's an experienced arch user. Otherwise I'd have to grab a docker image or vm or something and try myself, and I'm pretty overbooked at the moment |
|
The better workaround is to use cmake with |
|
Yes, that's definitely better. I did improve the documentation and structure of the associated file in this branch, including some TODOs that might be relevant: https://github.com/rpavlik/OpenXR-SDK-Source/tree/debug-cmake-gcc11 |
|
Just posting so it's not forgotten. It seems the cmake files are checking what flags are needed when compiling in c++17 mode, but c++17 mode isn't actually set when compiling the loader. So on gcc 11 it compiles with this diff --git a/src/loader/CMakeLists.txt b/src/loader/CMakeLists.txt
index 8638bc6..7ee9eb9 100644
--- a/src/loader/CMakeLists.txt
+++ b/src/loader/CMakeLists.txt
@@ -240,6 +240,8 @@ if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_C_COMPILER_ID MATCHES "Clang")
-ffunction-sections
-fdata-sections
)
+ set_property(TARGET openxr_loader PROPERTY CXX_STANDARD 17)
+
# Make build depend on the version script/export map
target_sources(openxr_loader PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/openxr-loader.map)
# Add the linker flag.But also looking back at my comment #260 (comment) I tried just removing the project wide c++14 setting and it worked too. diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 0c34992..af9e656 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -22,7 +22,6 @@ if(POLICY CMP0075)
endif()
# Entire project uses C++14
-set(CMAKE_CXX_STANDARD 14)
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
Someone more familiar with cmake and the c++ standard settings will need to decide what the right fix is. |
|
So what @ChristophHaag did is basically what my fix in #276 does: if it detects GCC 11+, it sets the configuration variable to indicate that C++17 is required for use of std::filesystem. Then everything works right. Telling GCC 11 to use C++14 in the project isn't persisting through to the try-compiles, so we're getting "yep we have c++17 std::filesystem" in the test builds that then fails at real compile time. |
Seems like for gcc the use of <filesystem> only works in c++17 mode. KhronosGroup/OpenXR-SDK-Source#260
Archlinux recently updated gcc to 11.1. Since then the openxr loader fails to compile.
probably something wrong with the logic in https://github.com/KhronosGroup/OpenXR-SDK-Source/blob/master/src/cmake/StdFilesystemFlags.cmake
workarounds:
1.
Possible cause: https://gcc.gnu.org/gcc-11/changes.html
The text was updated successfully, but these errors were encountered: