we are upgrading to boost 1.86.0 while preparing for an OS upgrade. I can not get rid of the unresolved symbol:
boost::log::v2s_mt_posix::aux::unhandled_exception_count() when linking.
We are upgrading from 1.69.0. Currently we are on Centos7 and are preparing for an upgrade to RHEL 9.4. We are building for Linux x86_64 and cross compiling for Petalinux aarch64.
I am linking with posix multithreading specified in my cmake files. This all worked fine under Boost 1.69.0 & cmake 3.25.1
The setup from my CMakeLists.txt is as follows:
cmake_minimum_required(VERSION 3.30.1)
set(CMAKE_TOOLCHAIN_FILE tc-x86_64.cmake)
project(MPDR3)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_CXX_STANDARD 20)
set(CXX_STANDARD 20)
set(CMAKE_C_STANDARD 17)
message("nBuild type is ${CMAKE_BUILD_TYPE}")
message(CMAKE_CXX_STANDARD = "${CMAKE_CXX_STANDARD}")
message(CMAKE_TOOLCHAIN_FILE = "${CMAKE_TOOLCHAIN_FILE}")
message(CMAKE_C_COMPILER = "${CMAKE_C_COMPILER}") # c++ complier is automatic...
# setup boost...
# we will use static libs
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
set(BOOST_ROOT $ENV{SDR_HOME}/thirdparty/boost_1_86_0/)
find_package(Boost 1.86.0 REQUIRED COMPONENTS log log_setup thread system program_options)
find_package(Threads)
include_directories(${Boost_INCLUDE_DIRS})
link_directories(${Boost_LIBRARY_DIRS})
message(STATUS "Boost version: ${Boost_VERSION}")
set(EIGEN3_ROOT $ENV{SDR_HOME}/thirdparty/eigen/)
find_package (Eigen3 3.4 REQUIRED NO_MODULE)
message("Eigan version: ${Eigan_VERSION}")
include_directories($ENV{SDR_HOME}/thirdparty/eigen/include/eigen3)
<snip>
Error comes when doing the link of my executable. The only answers I have found have been that I should link dynamically instead of statically. I get the same unresolved both ways. My default linking is static.
I have examined my LD_LIBRARY_PATH and don’t see any issues.
I have tried linking both statically and dynamically. I get the same error. The namespace indicates it is a function that should be resolved by something in boost logging, but when I grep the source code for the routine I find nothing.
I tried changing the order of log and log_setup, tried using log_mt…
Now I have tried linking under RHEL9.4.
Boost logging – getting unresolved symbol — this problem is almost the same… but I tried both solutions and did not get a different result.
Paul Martellock is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
The current Boost.Log does not provide unhandled_exception_count function, it switched to boost::core::uncaught_exceptions. If you’re having unresolved references to unhandled_exception_count then either you’re including headers from an older Boost.Log, which is still installed on the system, or some part of your program was not recompiled with the new Boost.Log and still depends on the old Boost. In the latter case, there may be some third party library that you’re using that was compiled against the older Boost. If so, you need to recompile it with the new Boost.
Try removing the old Boost headers from the system (for example, if it is installed as a CentOS package, try removing the corresponding -devel package). Also pay attention to the linking errors as they may contain the name of the object file that contains the outdated references. This may give you a clue which parts of the program are not recompiled with the new Boost.
1