CODEWITHSUNDEEP
c++g++shared-libraries
Steven Behnke
Steven Behnke

Reputation: 3344

Detecting / avoiding g++ symbol collisions

Is there a way to detect and avoid if two shared libraries both expose the same global scope symbols? We recently ran into a situation where we had libA.so that exported the SuperCoolMethod() and libB.so that also exposed the SuperCoolMethod() which would clobber the previous copy of said method. This is on Linux using g++ 4.0 and later. So in isolation if you link against libA.so everything would work as expected, but once libB.so was added to the picture the wrong method was called and the call would fail causing the executing thread to abort without notifying us of the potential problem. Through exhausting trial and error we eventually found the SuperCoolMethod() getting clobbered and notified the vendor of libB.so so that the __attribute__((visibility("hidden"))) can be applied to their copy of the method.

Upvotes: 1

Views: 586

Answers (3)

Scott Smith
Scott Smith

Reputation: 3986

As a work-around, if you only use one of the two methods, the order in which they appear on the link command line determines which version of the function you end up with in the final executable.

This isn't just an artifact, it's defined behavior, so you can depend on it (until the vendor fixes it).

Upvotes: 0

mmmmmm
mmmmmm

Reputation: 32661

As this is C++ the libraries each ought to be in their own namespace so collisions do no occur.

Upvotes: 1

pm100
pm100

Reputation: 50120

dynamically loading the library and attaching the symbols via dlopen and dlsym would work. You would have to write code to do it but if you were really truly stuck it would be a solution

Upvotes: 0

Related Questions