Closed valentinegb closed 1 month ago
That looks like an issue with the upstream build system on macOS. Can you reproduce the issue in a fresh clone of https://github.com/KhronosGroup/OpenXR-SDK? If so, please open an issue on that repository.
Otherwise, can you reproduce it on the release-1.0.25
tag, but not on main? If so, then you can probably work around the issue by using a git dep on this crate, and we should make a new release.
Same thing on main
. I've cloned the SDK but realized there aren't any instructions for building on Mac, is it not currently possible?
I copied the commands that were executed by the build script and ran them on the fresh clone, got the same output.
Found these directions and they seem to work on the fresh clone.
Interesting. What are the exact commands the build script runs in your environment? I'm not much of a cmake expert, but this feels like it's probably bad practice somewhere in the cmake
crate or the upstream build system...
It's the line in the output I gave in the original comment that starts with running:
running: cd "/Users/valentinebriese/Developer/bevy-openxr/target/debug/build/openxr-sys-cfd644a5713c7f7b/out/build" && CMAKE_PREFIX_PATH="" "cmake" "/Users/valentinebriese/.cargo/registry/src/index.crates.io-6f17d22bba15001f/openxr-sys-0.9.3/OpenXR-SDK" "-DCMAKE_OSX_ARCHITECTURES=arm64" "-DBUILD_API_LAYERS=OFF" "-DBUILD_TESTS=OFF" "-DOpenGL_GL_PREFERENCE=GLVND" "-DDYNAMIC_LOADER=OFF" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_PREFIX=/Users/valentinebriese/Developer/bevy-openxr/target/debug/build/openxr-sys-cfd644a5713c7f7b/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -arch arm64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -arch arm64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -arch arm64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Release"
I modified this slightly to use the directory of the fresh clone, and created the out/build
subdirectory beforehand.
Right, thanks. I'm guessing the cmake
crate doesn't use xcode because it wants to have minimal dependencies and avoid idiosyncrasy, and upstream OpenXR only tests the Xcode generator. I think the most practical fix would be to get the upstream build working with whatever the default generator is. I'm not equipped to work on that myself, but you can work around the issue by placing your hand-built libopenxr in the linker search path somewhere and using the linked
feature of this crate in the mean time.
I have added
openxr
as a dependency to my project like so:cargo build
results in this error:I am on a 2020 M1 MacBook Air running macOS 14.3 Beta (23D5033f).