2

I have an executable E which (I assume) dynamically loads (dlopen) a library file A.so. File A.so dynamically links B.so which is produced by me. In B.so I statically link a number of libraries, e.g. Boost (let's call this static boost library C1). Only B is fully under my control. A only partially (I can add some linker flags, for example).

It seems that E is also linking an older version of Boost dynamically. Let's call this Boost library C2. When I run E and code from B is used, it resolves Boost symbols from C2 (more specifically regarding the serialization library) and this causes crashes as those are not compatible with the code in B which statically links C1.

How can I make sure B is always using the symbols from the statically linked Boost library and not from any dynamically linked library? Or more general, I actually want to ensure this for all libraries I statically link into B.

Some more information:

  • I checked the dependencies of B with ldd and they do not refer to a Boost library.
  • I think the problem might be due C2 exporting serialization symbols and B exporting weak symbols (inspected using nm -D). I cannot change C2 and I am not sure how to hide the weak Boost symbols in B.
  • I use the --retain-symbols-file option of ld to control which symbols I want to export from B.
  • I also tried using the --version-script or --dynamic-list instead of using the --retain-symbols-file option.
  • I tried using -Bsymbolic together with --whole-archive when linking the static libraries into B, but it did not solve the issue.
  • I do not want to use the visibility attribute in my code, as I want to be able to link the same code using different export configurations.
Coert Metz
  • 894
  • 6
  • 21
  • > _"(I assume)"_ - why assume? Use ldd/depends.exe to find out; strace or depends.exe/debugger for truly dynamic loads – sehe Jul 17 '15 at 21:07
  • > "How can I make sure B is always using the symbols from the statically linked Boost library and not from any dynamically linked library?" - I don't think it's possible for statically linked symbols to get "magically" runtime-resolved differently. Whatever is conflicting was not statically linked to begin with, I'd say – sehe Jul 17 '15 at 21:11

1 Answers1

0

You mention B doesn't dynamically link any boost library. Therefore, it's not likely that the problem involves boost symbols.

Your worries about weak symbols exported from B seem to be reversed. If exports of B would conflict, that would rather have to replace the symbols for C2 (which however is logically loaded before A -> B -> C1). I don't think these are the culprits.

What other libraries are gettig dynamically linked?

Specifically I suspect ABI incompatibilities between C/C++ runtime libraries. You might want to find out what compiler version/options were used by the host application.

Also, is the interface between (E->A) C or C++?

Is the interface between (A->B) C or C++?

sehe
  • 374,641
  • 47
  • 450
  • 633
  • Interface between E/A is C++, interface between A/B C. All software is build using the same compiler; only A and B by me. I tried using hidden visibility for all libraries and explicit export using the visibility attribute, which works fine. I suspect the Boost library, as I get a stack trace when running code in B using Boost serialization and in this stack trace the dynamic Boost serialization library is mentioned. – Coert Metz Jul 20 '15 at 19:17