2011-06-18 18 views
5

buduję wspólną bibliotekę z GCC 4.5.2 i Boost 1.46.1 (skompilowany z --build-type=complete) i jest to polecenie z Makefile, który robi part Szkielet:Problem łączenie Boost.Filesystem statycznie do udostępnionej biblioteki

$(CXX) -static -lboost_filesystem -fpic -shared $^ -o [email protected] 

Wszystko kompiluje grzywny, ale pojawia się następujący komunikat o błędzie, gdy zostanie załadowany przez aplikację:

plugins/crashdetect.so: undefined symbol: _ZN5boost11filesystem34path21wchar_t_codecvt_facetEv 

ldd wyjścia:

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) 

Uważam, że oznacza to, że łączyło statycznie Boost.

To co nm crashdetect.so -u | grep boost mówi:

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 

Więc myślę, że skoro symbol idzie pierwszy na tej liście to najprawdopodobniej nie ma nic specjalnego.

Czy brakuje mi czegoś?

EDIT: Więc to niemożliwe, czy co?

+2

Dlaczego statycznie łączysz biblioteki ze wspólną biblioteką? Czy to nawet obsługiwany tryb działania? – bdonlan

+0

@bdonlan: Cóż, nie jestem ekspertem od Linuksa, ale w systemie Windows udało mi się statycznie powiązać biblioteki z bibliotekami DLL. – szx

+0

Spróbuj zmienić kolejność argumentów: '$ (CXX) -fpic -shared $^-o $ @ -static -lboost_filesystem' –

Odpowiedz

3

Wierzę, że:

  1. Korzystanie z -static i -shared nie jest właściwa droga. Jedynym bardziej lub mniej niezawodny sposób kontrolować łączenie byłoby:

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

    na końcu linii poleceń.

  2. Nie można połączyć z boost_system.

  3. Awaria dzieje się, ponieważ wydaje się, że faktycznie link do statycznej wersji boost_filesystem. Jednakże, ponieważ jest on określony w linii poleceń przed plikami obiektów, żaden symbol nie jest w rzeczywistości wyciągany z niego, a każde odniesienie do funkcji boost.filesystem pozostaje niezdefiniowane. I tak, linker skarży się na pierwszy niezdefiniowany symbol.

Powiązane problemy