4

Background:

I'm porting an huge project to a new toolchain (from gcc 4.7.0 to gcc 8.2.0 and from boost 1.55 to boost 1.68). The whole SDK is generated by Yocto. There are several libraries and applications, all built with cmake.

The problem:

All the libraries just build and link fine, meanwhile some of the applications that use boost::thread does not link properly. Following an example:

The cmake generated command:

cd /home/italia.priv.org/user/workspace-mk5/git/build/apps/ConfigMngr && /opt/cmake-3.13.0-Linux-x86_64/bin/cmake -E cmake_link_script CMakeFiles/ConfigMngr.dir/link.txt --verbose=1 /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ --sysroot=/opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi --std=c++11 -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -fpermissive -O3 -DNDEBUG -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed CMakeFiles/ConfigMngr.dir/src/AppConfig.cpp.o CMakeFiles/ConfigMngr.dir/src/AppMain.cpp.o CMakeFiles/ConfigMngr.dir/src/AppStates.cpp.o CMakeFiles/ConfigMngr.dir/src/ConfigMngr.cpp.o CMakeFiles/ConfigMngr.dir/src/dbus_server/ConfigMngrServerApi.cpp.o -o ConfigMngr -Wl,-rpath,/home/italia.priv.org/user/workspace-mk5/git/targetfs/lib_priv/lib_arm: /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_chrono-mt.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_date_time-mt.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_filesystem-mt.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_system-mt.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_serialization-mt.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_thread-mt.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_timer-mt.so ../../../targetfs/lib_priv/lib_arm/libxxx_autocheck.so ../../../targetfs/lib_priv/lib_arm/libxxx_config.so ../../../targetfs/lib_priv/lib_arm/libxxx_dbusapi.a ../../../targetfs/lib_priv/lib_arm/libxxx_hwifc.a ../../../targetfs/lib_priv/lib_arm/libxxx_log.so ../../../targetfs/lib_priv/lib_arm/libxxx_utils.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libdbus-cxx.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libsigc-2.0.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libodb.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libodb-sqlite.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libodb-boost.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libsqlite3.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libdbus-1.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_date_time-mt.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_atomic-mt.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_chrono-mt.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_filesystem-mt.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libboost_system-mt.so ../../../targetfs/lib_priv/lib_arm/libxxx_core.so /opt/poky/2.6.2/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/libgtest.a -pthread

As you can see in bold libboost_thread is passed to the linker (it is a link to the actual lib). The command above outputs:

/opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'boost::this_thread::interruption_point()' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'boost::thread::native_handle()' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'boost::thread::do_try_join_until_noexcept(boost::detail::mono_platform_timepoint const&, bool&)' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'typeinfo for boost::detail::thread_data_base' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'boost::detail::get_current_thread_data()' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'boost::this_thread::interruption_requested()' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'boost::detail::thread_data_base::~thread_data_base()' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'boost::thread::detach()' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'boost::chrono::steady_clock::now()' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'boost::thread::join_noexcept()' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'boost::thread::interrupt()' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'boost::thread::start_thread_noexcept()' /opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'vtable for boost::detail::thread_data_base'

Looking at the symbols exported by libxxx_core and grepping for one of the undefined reference:

nm -DC libxxx_core.so | grep thread::native_handle
U boost::thread::native_handle()     

U => The symbol is undefined.

Then looking for the same symbol in libboost_thread:

nm -DC libboost_thread.so.1.68.0 | grep native_handle
0000c3b1 T boost::thread::native_handle()

T => The symbol is in the text (code) section.

So the linker should be able to solve this dependency (and the others).

What we have tried

  • Reordering the libraries (libxx_core before and after libboost_thread)
  • Checking each symbols that is not resolved
  • Tried different enviroments

Among the undefined reference, the last error given by the linker is

/opt/poky/2.6.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/real-ld: ../../../targetfs/lib_priv/lib_arm/libxxx_core.so: undefined reference to 'vtable for boost::detail::thread_data_base'

Probably there is something related to undefined references. I'm working on it too.

The question

Any idea about what could cause these errors or a suggestion on how to debug this behavior properly?

Thanks, Gabriele

gabbla
  • 269
  • 4
  • 11
  • check whether `libboost_thread-mt.so` is a link to `libboost_thread.so` – Oleksandr Kravchuk May 24 '19 at 15:55
  • @OleksandrKravchuk checked, and it actually link to `libboost_thread.so` in the same path – gabbla May 27 '19 at 06:14
  • search in sysroot whether there are any other boost-thread* libs – Oleksandr Kravchuk May 27 '19 at 14:08
  • I would recommend to use "bitbake -e" to have access to all information you need. For example you would like to know which package from boost are installed with `bitbake -e boost` and checking what exactly does the `do_install` function. Anyway I think you solved your specific problem by modifying your build configuration, isn't it? – fiorentinoing Jul 13 '21 at 15:09

0 Answers0