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.
views:
112answers:
3
A:
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
pm100
2010-02-10 02:01:15
Hmm, that might work since we never use the need to explicitly call the function in question, but it doesn't tell me how to discover the conflict to begin with.
Steven Behnke
2010-02-10 02:40:56
a combination of nm and grep will tell you
pm100
2010-02-10 18:05:21
+1
A:
As this is C++ the libraries each ought to be in their own namespace so collisions do no occur.
Mark
2010-02-10 02:09:23
If you can "notified the vendor of libB.so so that the __attribute((visibility("hidden"))" you can ask for namespaces which would work on non gnu compilers as well
Mark
2010-02-10 13:21:54
A:
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).
Scott Smith
2010-02-10 05:01:25