Home/ Questions/Q 6049189
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T07:32:51+00:00

I’m building a shared library with GCC 4.5.2 and Boost 1.46.1 (compiled with –build-type=complete

  • 0

I’m building a shared library with GCC 4.5.2 and Boost 1.46.1 (compiled with --build-type=complete) and this is a command from Makefile which does the linkage part:

$(CXX) -static -lboost_filesystem -fpic -shared $^ -o $@

Everything compiles fine but I get the following error when it gets loaded by application:

plugins/crashdetect.so: undefined symbol: _ZN5boost11filesystem34path21wchar_t_codecvt_facetEv

lddoutputs:

linux-gate.so.1 =>  (0x002f8000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x00bf5000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x0032d000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00506000)
/lib/ld-linux.so.2 (0x006f6000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x00110000)

I beleive this means that it linked Boost statically.

This is what nm crashdetect.so -u | grep boost says:

 U _ZN5boost11filesystem34path21wchar_t_codecvt_facetEv
 U _ZN5boost11filesystem36detail13dir_itr_closeERPvS3_
 U _ZN5boost11filesystem36detail28directory_iterator_constructERNS0_18directory_iteratorERKNS0_4pathEPNS_6system10error_codeE
 U _ZN5boost11filesystem36detail28directory_iterator_incrementERNS0_18directory_iteratorEPNS_6system10error_codeE
 U _ZN5boost11filesystem36detail6statusERKNS0_4pathEPNS_6system10error_codeE
 U _ZN5boost6system15system_categoryEv
 U _ZN5boost6system16generic_categoryEv
 U _ZNK5boost11filesystem315directory_entry12m_get_statusEPNS_6system10error_codeE

So I think since that symbol goes first in this list then most likely there’s nothing special about it.

Am I missing something?

EDIT:
So is this impossible or what?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I believe that:

    1. Your use of -static and -shared is not the right way. The only more-or-less reliable way to control linking would be:

      -Wl,-Bstatic -lboost_filesystem -Wl,-Bshared

      at the end of the command line.

    2. You fail to link to boost_system.

    3. The failure happens because you seem to actually link to the static version of boost_filesystem. However, because it’s specified on the command line before any object files, no symbol is actually pulled from it, and every reference to boost.filesystem functions remains undefined. And yes, the linker complains on the first undefined symbol.

    • 0