Problem linking Boost.Filesystem statically to a shared library

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 _ZN5boost11filesystem36d开发者_运维问答etail28directory_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?

---

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.