Stripping linux shared libraries

Question

We've recently been asked to ship a Linux version of one of our libraries, previously we've developed under Linux and shipped for Windows where deploying libraries is generally a lot easier. The problem we've hit upon is in stripping the exported symbols down to only those in the exposed interface. There are three good reasons for wanting to do this

• To protect the proprietary aspects of our technology from exposure through the exported symbols.
• To prevent users having problems with conflicting symbol names.
• To speed up the loading of the library (at least so I'm told).

Taking a simple example then:

test.cpp

#include <cmath>  float private_function(float f) {     return std::abs(f); }  extern "C" float public_function(float f) {     return private_function(f); } 

compiled with (g++ 4.3.2, ld 2.18.93.20081009)

g++ -shared -o libtest.so test.cpp -s 

and inspecting the symbols with

nm -DC libtest.so 

gives

         w _Jv_RegisterClasses 0000047c T private_function(float) 000004ba W std::abs(float) 0000200c A __bss_start          w __cxa_finalize          w __gmon_start__ 0000200c A _edata 00002014 A _end 00000508 T _fini 00000358 T _init 0000049b T public_function 

obviously inadequate. So next we redeclare the public function as

extern "C" float __attribute__ ((visibility ("default")))      public_function(float f) 

and compile with

g++ -shared -o libtest.so test.cpp -s -fvisibility=hidden 

which gives

         w _Jv_RegisterClasses 0000047a W std::abs(float) 0000200c A __bss_start          w __cxa_finalize          w __gmon_start__ 0000200c A _edata 00002014 A _end 000004c8 T _fini 00000320 T _init 0000045b T public_function 

which is good, except that std::abs is exposed. More problematic is when we start linking in other (static) libraries outside of our control, all of the symbols we use from those libraries get exported. In addition, when we start using STL containers:

#include <vector> struct private_struct {     float f; };  void other_private_function() {     std::vector<private_struct> v; } 

we end up with many additional exports from the C++ library

00000b30 W __gnu_cxx::new_allocator<private_struct>::deallocate(private_struct*, unsigned int) 00000abe W __gnu_cxx::new_allocator<private_struct>::new_allocator() 00000a90 W __gnu_cxx::new_allocator<private_struct>::~new_allocator() 00000ac4 W std::allocator<private_struct>::allocator() 00000a96 W std::allocator<private_struct>::~allocator() 00000ad8 W std::_Vector_base<private_struct, std::allocator<private_struct> >::_Vector_impl::_Vector_impl() 00000aaa W std::_Vector_base<private_struct, std::allocator<private_struct> >::_Vector_impl::~_Vector_impl() 00000b44 W std::_Vector_base<private_struct, std::allocator<private_struct> >::_M_deallocate(private_struct*, unsigned int) 00000a68 W std::_Vector_base<private_struct, std::allocator<private_struct> >::_M_get_Tp_allocator() 00000b08 W std::_Vector_base<private_struct, std::allocator<private_struct> >::_Vector_base() 00000b6e W std::_Vector_base<private_struct, std::allocator<private_struct> >::~_Vector_base() 00000b1c W std::vector<private_struct, std::allocator<private_struct> >::vector() 00000bb2 W std::vector<private_struct, std::allocator<private_struct> >::~vector() 

NB: With optimisations on you'll need to make sure the vector is actually used so the compiler doesn't optimise the unused symbols out.

I believe my colleague has managed to construct an ad-hoc solution involving version files and modifying the STL headers (!) that appears to work, but I would like to ask:

Is there a clean way to strip all unnecessary symbols (IE ones that are not part of the exposed library functionality) from a linux shared library? I've tried quite a lot of options to both g++ and ld with little success so I'd prefer answers that are known to work rather than believed to.

In particular:

• Symbols from (closed-source) static libraries are not exported.
• Symbols from the standard library are not exported.
• Non-public symbols from the object files are not exported.

Our exported interface is C.

I'm aware of the other similar questions on SO:

• NOT sharing all classes with shared library
• How to REALLY strip a binary in MacOs
• GNU linker: alternative to --version-script to list exported symbols at the command line?

but have had little success with the answers.

Answer 1

So the solution we have for now is as follows:

test.cpp

#include <cmath> #include <vector> #include <typeinfo>  struct private_struct {     float f; };  float private_function(float f) {     return std::abs(f); }  void other_private_function() {     std::vector<private_struct> f(1); }  extern "C" void __attribute__ ((visibility ("default"))) public_function2() {     other_private_function(); }  extern "C" float __attribute__ ((visibility ("default"))) public_function1(float f) {     return private_function(f); } 

exports.version

LIBTEST  { global:     public*; local:     *; }; 

compiled with

g++ -shared test.cpp -o libtest.so -fvisibility=hidden -fvisibility-inlines-hidden -s -Wl,--version-script=exports.version 

gives

00000000 A LIBTEST          w _Jv_RegisterClasses          U _Unwind_Resume          U std::__throw_bad_alloc()          U operator delete(void*)          U operator new(unsigned int)          w __cxa_finalize          w __gmon_start__          U __gxx_personality_v0 000005db T public_function1 00000676 T public_function2 

Which is fairly close to what we're looking for. There are a few gotchas though:

• We have to ensure we don't use the "exported" prefix (in this simple example "public", but obviously something more useful in our case) in the internal code.
• Many symbol names still end up in the string table, which appears to be down to RTTI, -fno-rtti makes them go away in my simple tests, but is a rather nuclear solution.

I'm happy to accept any better solutions anyone comes up with!

Answer 2

Your use of the default visibility attribute and -fvisibility=hidden should be augmented with -fvisibility-inlines-hidden.

You should also forget about trying to hide stdlib exports, see this GCC bug for why.

Also, if you have all of your public symbols in a specific headers you can wrap them in #pragma GCC visibility push(default) and #pragma GCC visibility pop instead of using attributes. Though if you are creating a cross platform library, take a look at Controlling Exported Symbols of Shared Libraries for a technique to unify your windows DLL and Linux DSO export strategy.