Wednesday, February 7, 2024

[SOLVED] undefined symbol - using log4cxx in centos 7

Issue

I've difficulty to make my snippet code working on centos 7.

So, I've these packages installed on the box:

log4cxx.x86_64, log4cxx-devel.x86_64, apr.x86_64, apr-devel.x86_64, apr-util.x86_64, apr-util-devel.x86_64, glib2.x86_64, glib2-devel.x86_64

in CMakeList.txt, I've tried bunch of combinations (successful build), but I ended up with same result when executing the binary.

Currently, I've this :

find_package(PkgConfig)
find_library(LOG4CXX_LIBRARY log4cxx)

Although I'm positive that it could find the library, but i also tried:

-llog4cxx -lapr-1 -laprutil-1 -lexpat -lglib-2.0

I built with both configs, and when i run the executable output, I'll get:

undefined symbol: _ZN7log4cxx3xml15DOMConfigurator9configureERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

The 'nm' output is:

$ nm -D /usr/lib64/liblog4cxx.so | grep _ZN7log4cxx3xml15DOMConfigurator9configure
00000000000f9ff0 T _ZN7log4cxx3xml15DOMConfigurator9configureERKSbIwSt11char_traitsIwESaIwEE
00000000000f9e40 T _ZN7log4cxx3xml15DOMConfigurator9configureERKSs

in my .cpp I've basically use this:

try {
    log4cxx::xml::DOMConfigurator::configure("/root/1.xml");
}
catch (log4cxx::helpers::Exception&) {
    fprintf( stderr, "Error on loading Log-config file" );
    return -1;
}

ps: Same project compiles and run on FreeBSD 12 with no issue.


Solution

This appears to be a C++ standard library ABI mismatch; the mismatched symbols demangle to:

log4cxx::xml::DOMConfigurator::configure(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)
log4cxx::xml::DOMConfigurator::configure(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)

Your comment indicates you're using GCC 10 in C++17 mode. CentOS 7 ships with GCC 4.8.5 (which doesn't even support C++17) which is much older, and predates the ABI change to std::basic_string in GCC 5.1 (first link above).

The pre-built libraries you've installed will have been built by the "default" CentOS 7 toolchain.

At first glance, I recommend building your dependencies from source, so that everything's built with the same toolchain.

It may be possible with some hackery, such as the _GLIBCXX_USE_CXX11_ABI macro, to make the two line up properly, but you'll need someone else come along to help with that if so.

(The char/wchar_t mismatch is also interesting, though I suspect that's just a red herring based on the order in which errors appeared.)



Answered By - Asteroids With Wings
Answer Checked By - Senaida (WPSolving Volunteer)
at