Compilation fails with sytem spdlog and libfmt
ConiKost opened this issue · comments
It looks like, that commit 0eda146 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)
Does #149 allow you to build with the system spdlog and libfmt? For me it failed to link properly.
Does #149 allow you to build with the system spdlog and libfmt? For me it failed to link properly.
Unfortunately not.
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
-)
@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 #149 (comment).
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.
@lisanna-dettwyler Thank you, I can confirm, that it works now.