Shared library name collisions

Question

I'm distributing a shared library (C++) and a python module that uses this library. I build a modified version of Bullet Physics Library (as a CMake subproject). I only use Bullet classes and functions in one file bullet_interface.cpp and all the Bullet stuff is hidden inside namespace { ... }.

The problem is that some other libraries require Bullet as a system dependency and link to the system version of Bullet. In fact, one of the dependencies of my library (libopenrave) exports Bullet symbols. (More specifically, it sometimes dynamically loads a plugin that exports Bullet symbols).

I'm wondering if there's a way to build my library so bullet_interface.cpp uses the correct Bullet functions, but then my library doesn't make any of the Bullet symbols visible. I can't use the system bullet because I had to make changes to the source code. One hacky solution would be to rename all of the Bullet functions and classes using a search and replace (almost all contain the string "bt"). Is there a better way?

Wilinski

The obvious solution is to get your fixes into the main Bullet library and use THAT as the system library. – Alfredoalfresco

Can you just ensure your modified version is loaded first and satisfies all the dependencies in the other libraries, so they don't need the system one? – Shandra

So libopenrave exports bullet symbols and links with bullet library, while your plugin uses exactly the same bullet symbols and is being shipped with the modified bullet library? If so, you may try to build your modified bullet library as a static lib, link it into your plugin, and ensure that all bullet symbols in your plugin are hidden. Your plugin code will use them, while they will not be exported in dynamic symbol table. If bullet makefiles or code attributes are explicitly setting visibility, you'll have to hack it, maybe using binutils to change symbol visibility before linking objects? – Evocative

I have a partial solution, building on Al's suggestion. (1) I set -fvisibility=hidden and use a DLL_EXPORT macro to control visibility. (2) instead of linking to a bullet shared library, I made a unity build of bullet (i.e., a cpp file that includes all of the bullet cpp files) and I build that along with my shared lib. Now my library isn't exporting any bullet symbols. Unfortunately, I still get a name collision when the system Bullet shared library gets loaded. – Wilinski

What platform is this? Runtime linker behaviour isn't particularly portable ... – Steading

Answer 1

This is a bit of a roundabout way to accomplish what you want, but it beats a search-and-replace in bullet code.

You can try 'prefixing' symbols in the bullet library using the objcopy utility like this:

objcopy --prefix-symbols=old_ bullet.a

This should work with a dynamic library as well, but you'll have to try it. See this answer for details.

Adulterous