search

KhronosGroup / OpenXR-SDK-Source

Sources for OpenXR loader, basic API layers, and example code.
https://khronos.org/openxr
Apache License 2.0
663 stars 247 forks source link

jsoncpp issue causes OpenXR SDK 1.1.38+ to not compile anymore #509

Open LordOfDragons opened 5 days ago

LordOfDragons commented 5 days ago

This jsoncpp issue causes OpenXR SDK 1.1.38 up to 1.1.41 to fail compiling:

-- The C compiler identification is GNU 13.3.1
-- The CXX compiler identification is GNU 13.3.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Python3: /usr/bin/python3.12 (found version "3.12.6") found components: Interpreter
-- Performing Test HAVE_FILESYSTEM_WITHOUT_LIB
-- Performing Test HAVE_FILESYSTEM_WITHOUT_LIB - Failed
-- Performing Test HAVE_FILESYSTEM_NEEDING_LIBSTDCXXFS
-- Performing Test HAVE_FILESYSTEM_NEEDING_LIBSTDCXXFS - Success
-- Performing Test HAVE_FILESYSTEM_NEEDING_LIBCXXFS
-- Performing Test HAVE_FILESYSTEM_NEEDING_LIBCXXFS - Failed
-- Found OpenGL: /usr/lib64/libOpenGL.so
-- Enabling OpenGL support
-- Found Vulkan: /usr/lib64/libvulkan.so (found version "1.3.290") found components: glslc glslangValidator
-- Enabling Vulkan support
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
CMake Error at /usr/lib64/cmake/jsoncpp/jsoncppConfig.cmake:37 (check_required_components):
  Unknown CMake command "check_required_components".
Call Stack (most recent call first):
  src/cmake/FindJsonCpp.cmake:68 (find_package)
  src/CMakeLists.txt:125 (find_package)

-- Configuring incomplete, errors occurred!
RunExternalCommand failed for script:
export CC="gcc"
export CXX="g++"
export AS="as"
export AR="ar"
export RANLIB="ranlib"
cd "/home/roland/progs/dragengine/extern/openxr/build/OpenXR-SDK-release-1.1.41" || exit 1
cmake -DCMAKE_INSTALL_PREFIX="/home/roland/progs/dragengine/extern/openxr/build" -DCMAKE_INSTALL_LIBDIR="/home/roland/progs/dragengine/extern/openxr/build/lib" -DCMAKE_BUILD_TYPE=Release -DBUILD_API_LAYERS=No -DBUILD_TESTS=No -DBUILD_WITH_STD_FILESYSTEM=No -DBUILD_WITH_SYSTEM_JSONCPP=No -DBUILD_WITH_WAYLAND_HEADERS=No -DBUILD_WITH_XCB_HEADERS=No -DDYNAMIC_LOADER=No -Wno-dev ../OpenXR-SDK-release-1.1.41 || exit 1
make -j 12 install || exit 1

The problem started happening after a system update where gcc/cmake has been updated:

gcc (Gentoo 13.3.1_p20240614 p17) 13.3.1 20240614
cmake version 3.30.2

The only workaround I found so far is this patch. But this requires jsoncpp to be build using BUILD_WITH_SYSTEM_JSONCPP=No and is thus really just a workaround and no fix.

rpavlik commented 5 days ago

OK, thank you for the log. It looks like your system jsoncpp install is actually broken, presumably because the system package is built with meson and uses a version that makes a broken config file if built with meson. (If you generate the config file with cmake, an impl of check_required_components is generated in there too.) I am pretty sure their "patch" does not actually fix the problem, or rather, it breaks the usage for everyone now, but won't error...

As a workaround, run CMake with `-DCMAKE_DISABLE_FIND_PACKAGE_jsoncpp=TRUE" to skip that check and force using the internal build.

So what system are you using? Gentoo? So there is a Gentoo bug. Unfortunately this is a tricky one to work around in our consuming package.

rpavlik commented 5 days ago

I updated the corresponding upstream (jsoncpp) bug with details: https://github.com/open-source-parsers/jsoncpp/issues/1568#issuecomment-2417485183

I do not have time to look into how to file a Gentoo bug.

LordOfDragons commented 5 days ago

Created Gentoo bug linking to this issue and the upstream fix attempt: https://bugs.gentoo.org/941642

LordOfDragons commented 5 days ago

I've got the impression the ball is kicked back into your yard: https://bugs.gentoo.org/941642#c1

LordOfDragons commented 1 day ago

The fix on the gentoo jsoncpp ebuild fixes the problem. Not sure about other distros using the same jsoncpp version.

rpavlik commented 8 hours ago

If they used CMake instead of Meson they would have had no problem, it was only if they used Meson but shipped the buggy meson-generated CMake config file.

So with the Gentoo fix things work fine now, by just falling back to pkg-config? It has less info about what kind of library we're talking about, but it should be good enough.

LordOfDragons commented 6 hours ago

You can try asking up-up-stream if they can do a real fix for CMake. For compiling OpenXR it seems to work.