Boost on darwin statically including libstdc++?

StackOverflow https://stackoverflow.com/questions/11164016

Question

Why does STL code seem to be statically linked into the Boost dynamic libraries on Darwin?

When I build Boost 1.42/1.46.1/1.49 on OS X with gcc 4.6.1 and toolset=darwin, I find that the resulting libraries statically include a lot of STL code, such as std::basic_string<char> and std::basic_string<wchar_t>.

Building on OS X 10.6.8, I get the following results:

% otool -L /usr/local/boost-1.46.1/lib/libboost_system.dylib
boost-1.46.1/lib/libboost_system.dylib:
    libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
    /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

Based on the 'otool -L' output, it's clear that libstdc++ is not dynamically linked with the library. By comparison, on Ubuntu 12.04 LTS, libboost_system.so 1.46.1 shows the following linking:

% ldd /usr/local/lib/libboost_system.so
    linux-vdso.so.1 =>  (0x00007fff495ff000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fec4edb4000)
    libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00007fec4ea82000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fec4e788000)
    libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00007fec4e573000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fec4e355000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec4df98000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fec4f1e4000)

In this case libstdc++ has clearly been dynamically linked. On the OS X side, this is how I know that STL code has been included directly in the Boost library:

% nm -gfj /usr/local/boost-1.46.1/lib/libboost_system.dylib | c++filt --format=gnu-v3 | egrep "^std::basic_string"
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_disjunct(char const*) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char const*, unsigned long) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char const*, unsigned long, unsigned long) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char, unsigned long) const
... [180 more lines] ...
Was it helpful?

Solution

Just to pick on one example: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char const*, unsigned long) const

std::basic_string is a template class, and does not exist in libstdc++.dylib. It was instantiated when the boost library was compiled, and (rightly) included there - because Boost.System uses it.

I suspect (but don't know) that this is true for all of the calls you see.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top