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?
Dlaczego statycznie łączysz biblioteki ze wspólną biblioteką? Czy to nawet obsługiwany tryb działania? – bdonlan
@bdonlan: Cóż, nie jestem ekspertem od Linuksa, ale w systemie Windows udało mi się statycznie powiązać biblioteki z bibliotekami DLL. – szx
Spróbuj zmienić kolejność argumentów: '$ (CXX) -fpic -shared $^-o $ @ -static -lboost_filesystem' –