Compilation fails with sytem spdlog and libfmt

[ConiKost]

It looks like, that commit https://github.com/oneapi-src/level-zero/commit/0eda14664e96fe313c7772fe83c95d21a8288823 broke something or exposed some bug. @Jemale

Compiling level-zero-1.16.14 while already having installed spdlog and libfmt fails in compilation. See Gentoo downstream bug fore mor analysis by sam. https://bugs.gentoo.org/930157

[48/51] : && /usr/bin/x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -fno-diagnostics-color -std=c++14 -fpermissive -fPIC -Wall  -Wnon-virtual-dtor -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0    -rdynamic samples/zello_world/CMakeFiles/zello_world.dir/zello_world.cpp.o -o bin/zello_world  -Wl,-rpath,/var/tmp/portage/dev-libs/level-zero-1.16.14/work/level-zero-1.16.14_build/lib  lib/libze_loader.so.1.16.14  -ldl  lib/libutils.a && :
FAILED: bin/zello_world 
: && /usr/bin/x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -fno-diagnostics-color -std=c++14 -fpermissive -fPIC -Wall  -Wnon-virtual-dtor -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0    -rdynamic samples/zello_world/CMakeFiles/zello_world.dir/zello_world.cpp.o -o bin/zello_world  -Wl,-rpath,/var/tmp/portage/dev-libs/level-zero-1.16.14/work/level-zero-1.16.14_build/lib  lib/libze_loader.so.1.16.14  -ldl  lib/libutils.a && :
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `fmt::v9::detail::throw_format_error(char const*)'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `typeinfo for fmt::v9::format_error'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `fmt::v9::format_error::~format_error()'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `char fmt::v9::detail::decimal_point_impl<char>(fmt::v9::detail::locale_ref)'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `fmt::v9::detail::assert_fail(char const*, int, char const*)'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `fmt::v9::detail::thousands_sep_result<char> fmt::v9::detail::thousands_sep_impl<char>(fmt::v9::detail::locale_ref)'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `fmt::v9::detail::dragonbox::decimal_fp<float> fmt::v9::detail::dragonbox::to_decimal<float>(float)'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `fmt::v9::vformat[abi:cxx11](fmt::v9::basic_string_view<char>, fmt::v9::basic_format_args<fmt::v9::basic_format_context<fmt::v9::appender, char> >)'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `fmt::v9::detail::dragonbox::decimal_fp<double> fmt::v9::detail::dragonbox::to_decimal<double>(double)'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `fmt::v9::format_system_error(fmt::v9::detail::buffer<char>&, int, char const*)'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `vtable for fmt::v9::format_error'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libze_loader.so.1.16.14: undefined reference to `fmt::v9::detail::is_printable(unsigned int)'
collect2: error: ld returned 1 exit status
[49/51] /usr/bin/x86_64-pc-linux-gnu-g++ -DL0_LOADER_VERSION=\"1\" -DL0_VALIDATION_LAYER_SUPPORTED_VERSION=\"1\" -DLOADER_VERSION_MAJOR=1 -DLOADER_VERSION_MINOR=16 -DLOADER_VERSION_PATCH=14 -Dze_tracing_layer_EXPORTS -I/var/tmp/portage/dev-libs/level-zero-1.16.14/work/level-zero-1.16.14/include -I/var/tmp/portage/dev-libs/level-zero-1.16.14/work/level-zero-1.16.14/source/wrapper/include -I/var/tmp/portage/dev-libs/level-zero-1.16.14/work/level-zero-1.16.14_build/_deps/spdlog-src/include -I/var/tmp/portage/dev-libs/level-zero-1.16.14/work/level-zero-1.16.14 -I/var/tmp/portage/dev-libs/level-zero-1.16.14/work/level-zero-1.16.14/source/inc -I/var/tmp/portage/dev-libs/level-zero-1.16.14/work/level-zero-1.16.14/source/layers/tracing  -O2 -pipe -march=native -fno-diagnostics-color -std=c++14 -fpermissive -fPIC -Wall  -Wnon-virtual-dtor -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -fPIC -fno-diagnostics-color -MD -MT source/layers/tracing/CMakeFiles/ze_tracing_layer.dir/ze_trcddi.cpp.o -MF source/layers/tracing/CMakeFiles/ze_tracing_layer.dir/ze_trcddi.cpp.o.d -o source/layers/tracing/CMakeFiles/ze_tracing_layer.dir/ze_trcddi.cpp.o -c /var/tmp/portage/dev-libs/level-zero-1.16.14/work/level-zero-1.16.14/source/layers/tracing/ze_trcddi.cpp
ninja: build stopped: subcommand failed.

This patch seems to work as workaround:

Find the system copy of spdlog which then tells us how to link
against both it & libfmt correctly, rather than accidentally
picking up system spdlog headers and nothing else (defines, needed
libraries, etc) when (for some reason?) FetchContent fails and we don't
realise it.

TODO: Figure out why FetchContent(?) failing doesn't kill the build
TODO: Add a proper option for this to use the system copy/not

Bug: https://bugs.gentoo.org/930157
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -57,9 +57,6 @@ elseif(Git_FOUND)
    endif()
 endif()

-include(FetchContent)
-set(SPDLOG_ROOT "${FETCHCONTENT_BASE_DIR}/spdlog-src")
-
 # Update other relevant variables to include the patch
 set(PROJECT_VERSION "${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}.${PROJECT_VERSION_PATCH}")
 set(CMAKE_PROJECT_VERSION_PATCH "${PROJECT_VERSION_PATCH}")
@@ -166,7 +163,6 @@ endif()

 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include)
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/source/wrapper/include)
-include_directories(${SPDLOG_ROOT}/include)

 include_directories("${CMAKE_CURRENT_SOURCE_DIR}")

diff --git a/source/utils/CMakeLists.txt b/source/utils/CMakeLists.txt
index cb6cfb1..4e486d8 100644
--- a/source/utils/CMakeLists.txt
+++ b/source/utils/CMakeLists.txt
@@ -1,23 +1,11 @@
 # Copyright (C) 2024 Intel Corporation
 # SPDX-License-Identifier: MIT

-include(FetchContent)
-set(SPDLOG_REPO https://github.com/gabime/spdlog)
-set(SPDLOG_TAG v1.13.0)
-FetchContent_Declare(
-    spdlog
-    GIT_REPOSITORY ${SPDLOG_REPO}
-    GIT_TAG ${SPDLOG_TAG}
-)
-FetchContent_makeAvailable(spdlog)
+find_package(spdlog)

 add_library(utils
-  STATIC
   "logging.h"
   "logging.cpp"
 )

-target_include_directories(utils
-  PUBLIC
-  ${FETCHCONTENT_BASE_DIR}/spdlog-src/include
-)
+target_link_libraries(utils spdlog::spdlog)

[loqs]

Does https://github.com/oneapi-src/level-zero/pull/149 allow you to build with the system spdlog and libfmt? For me it failed to link properly.

[ConiKost]

Does https://github.com/oneapi-src/level-zero/pull/149 allow you to build with the system spdlog and libfmt? For me it failed to link properly.

Unfortunately not.

[luyatshimbalanga]

Hello, on Fedora Linux side, we face the same issue with the compilation attempting to clone online git spdlog repository which is disallowed in the Fedora build system. We have a working patch addressing the problem and it will be nice the team fixes the compilation issue by using the existing available system library.

Here is the full list of the patch file oneapi-level-zero-spdlog.patch

diff -up level-zero-1.17.2/CMakeLists.txt.spdlog level-zero-1.17.2/CMakeLists.txt
--- level-zero-1.17.2/CMakeLists.txt.spdlog 2024-05-22 16:25:52.000000000 -0600
+++ level-zero-1.17.2/CMakeLists.txt    2024-05-22 19:52:35.669074005 -0600
@@ -78,9 +78,6 @@ else()
 endif()
 add_definitions(-DLOADER_VERSION_SHA="${VERSION_SHA}")

-include(FetchContent)
-set(SPDLOG_ROOT "${FETCHCONTENT_BASE_DIR}/spdlog-src")
-
 # Update other relevant variables to include the patch
 set(PROJECT_VERSION "${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}.${PROJECT_VERSION_PATCH}")
 set(CMAKE_PROJECT_VERSION_PATCH "${PROJECT_VERSION_PATCH}")
@@ -187,7 +184,6 @@ endif()

 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include)
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/source/wrapper/include)
-include_directories(${SPDLOG_ROOT}/include)

 include_directories("${CMAKE_CURRENT_SOURCE_DIR}")

diff -up level-zero-1.17.2/source/utils/CMakeLists.txt.spdlog level-zero-1.17.2/source/utils/CMakeLists.txt
--- level-zero-1.17.2/source/utils/CMakeLists.txt.spdlog    2024-05-22 16:25:52.000000000 -0600
+++ level-zero-1.17.2/source/utils/CMakeLists.txt   2024-05-22 19:58:08.784416938 -0600
@@ -1,23 +1,8 @@
 # Copyright (C) 2024 Intel Corporation
 # SPDX-License-Identifier: MIT

-include(FetchContent)
-set(SPDLOG_REPO https://github.com/gabime/spdlog)
-set(SPDLOG_TAG v1.13.0)
-FetchContent_Declare(
-    spdlog
-    GIT_REPOSITORY ${SPDLOG_REPO}
-    GIT_TAG ${SPDLOG_TAG}
-)
-FetchContent_makeAvailable(spdlog)
-
 add_library(utils
   STATIC
   "logging.h"
   "logging.cpp"
 )
-
-target_include_directories(utils
-  PUBLIC
-  ${FETCHCONTENT_BASE_DIR}/spdlog-src/include
-)

[loqs]

@luyatshimbalanga that patch fails for me as it does not link to the system libraries. It would use the headers if they are already on the default search path. Could you explain how the system libraries are detected without using find_package or FindPkgConfig? See also https://github.com/oneapi-src/level-zero/pull/149#issuecomment-2126362948.

[lisanna-dettwyler]

https://github.com/oneapi-src/level-zero/releases/tag/v1.17.6 now bundles the spdlog headers needed and has no dependencies on system spdlog.

[ConiKost]

@lisanna-dettwyler Thank you, I can confirm, that it works now.