Suppressing boost.thread and boost.system symbols in shared library

Hi all, I am building a shared library for Linux, for which I would like to export as few symbols as possible (ideally only the functions that my library users actually need to call). When building my project, I have the following options: -fvisibility=hidden -fvisibility-inlines-hidden I then mark all the functions that I am exporting as having default visibility. I link to static versions of boost.thread and boost.system. When I then say: nm -DC libtest.so I get a large number of symbols such as: 0002abe0 V typeinfo name for boost::exception_detail::clone_impl<boost::exceptio n_detail::bad_exception_> 0002ace0 V typeinfo name for boost::exception_detail::bad_exception_ 00029920 V typeinfo name for boost::exception_detail::error_info_injector<boost: :lock_error> 00029b00 V typeinfo name for boost::exception_detail::error_info_injector<boost: :condition_error> 00029860 V typeinfo name for boost::exception_detail::error_info_injector<boost: :thread_resource_error> 0002970f V typeinfo name for boost::thread_exception 00029a7b V typeinfo name for boost::thread_interrupted 00029740 V typeinfo name for boost::thread_resource_error 0002ac40 V typeinfo name for boost::enable_shared_from_this<boost::detail::threa d_data_base> 0002a720 V typeinfo name for boost::detail::thread_data_base 0002ad20 V typeinfo name for boost::detail::sp_counted_impl_p<boost::detail::thr ead_data_base> 0002adc0 V typeinfo name for boost::detail::sp_counted_impl_p<boost::exception_d etail::clone_impl<boost::exception_detail::bad_alloc_> > 0002ad60 V typeinfo name for boost::detail::sp_counted_impl_p<boost::exception_d etail::clone_impl<boost::exception_detail::bad_exception_> > 000296f1 V typeinfo name for boost::system::system_error I see this after having stripped the binary. Is there any way to get rid of these? Do I need to build Boost with some special cxxflags? Kind regards, Philip Bennefall

On Thursday 01 August 2013 23:30:27 Philip Bennefall wrote:
Hi all,
I am building a shared library for Linux, for which I would like to export as few symbols as possible (ideally only the functions that my library users actually need to call). When building my project, I have the following options:
-fvisibility=hidden -fvisibility-inlines-hidden
I then mark all the functions that I am exporting as having default visibility. I link to static versions of boost.thread and boost.system. When I then say:
nm -DC libtest.so
I get a large number of symbols such as:
I see this after having stripped the binary. Is there any way to get rid of these? Do I need to build Boost with some special cxxflags?
You can pass compiler arguments in the cxxflags=... argument for bjam but that won't help much because you'll likely want to export RTTI symbols. You can apply a map file when linking your library (google for -Wl,--version- script=... argument). The map file should make all RTTI and your symbols public while hiding everything else. From my experience this approach is the most flexible. Note that you can still mark some of your functions as private/public by applying visibility attributes - the map file will only hide symbols that were left public by the compiler.

Hi Andrey, Thank you for your quick response! If I understand you correctly, I won't get the result I'm after by doing the following? ./b2 variant=release link=static runtime-link=static threading=multi cxxflags="-fvisibility=hidden -fvisibility-inlines-hidden" --with-system --with-thread If I could do something like that, it'd be ideal. Will this not work? Please keep in mind that I am relatively new to GCC so my questions may be basic. Kind regards, Philip Bennefall

On Thursday 01 August 2013 23:54:34 Philip Bennefall wrote:
Hi Andrey,
Thank you for your quick response! If I understand you correctly, I won't get the result I'm after by doing the following?
./b2 variant=release link=static runtime-link=static threading=multi cxxflags="-fvisibility=hidden -fvisibility-inlines-hidden" --with-system --with-thread
If I could do something like that, it'd be ideal. Will this not work?
It should compile with all symbols hidden unless marked otherwise.

Hi Andrey, I tested this, and while my shared library (which is the component that uses Boost internally) builds fine, when I try to link that with a test client program I get: .//libtest.so: undefined reference to `boost::system::system_category()' .//libtest.so: undefined reference to `boost::system::generic_category()' The client program doesn't talk to boost.system at all. Do you think this is due to the visibility options that I used while building thred and system? Should I just forget about it and leave the symbols in? Kind regards, Philip Bennefall

On Aug 1, 2013, at 6:50 PM, Philip Bennefall <philip@blastbay.com> wrote:
I tested this, and while my shared library (which is the component that uses Boost internally) builds fine, when I try to link that with a test client program I get:
.//libtest.so: undefined reference to `boost::system::system_category()' .//libtest.so: undefined reference to `boost::system::generic_category()'
The client program doesn't talk to boost.system at all. Do you think this is due to the visibility options that I used while building thred and system? Should I just forget about it and leave the symbols in?
If a symbol is marked hidden by just one link record, it will be hidden, even if all of the rest are visible. In this case, the clients get references to the symbols, because of your including Boost headers, but you've marked them hidden, so that hides them for the client, too. You should keep Boost headers out of your public headers or leave the typeinfo symbols visible. ___ Rob (Sent from my portable computation engine)

On Aug 1, 2013, at 5:30 PM, Philip Bennefall <philip@blastbay.com> wrote:
I am building a shared library for Linux, for which I would like to export as few symbols as possible (ideally only the functions that my library users actually need to call). When building my project, I have the following options:
-fvisibility=hidden -fvisibility-inlines-hidden
I then mark all the functions that I am exporting as having default visibility. I link to static versions of boost.thread and boost.system. When I then say:
nm -DC libtest.so
I get a large number of symbols such as:
0002abe0 V typeinfo name for boost::exception_detail::clone_impl<boost::exceptio n_detail::bad_exception_> 0002ace0 V typeinfo name for boost::exception_detail::bad_exception_
[snip] The typeinfo for any exceptions that might escape from your API must be visible, so they are marked that way. ___ Rob (Sent from my portable computation engine)
participants (3)
-
Andrey Semashev
-
Philip Bennefall
-
Rob Stewart