1

For background, see Symbol visibility, exceptions, runtime error.

I have a collection of Linux DSO's that are entirely under my own control. I wish to share STL containers amongst them. I have experienced mysterious SIGSEGV problems that appear to relate to ODR violations that in turn result from non-visible symbols.

It may be that the only sane answer here is to either gather all this code into one big DSO, or to give up on sharing STL containers. However, the purpose of this question is to look for an alternative. if the underlying problem is the default visibility rule, is there an option to change the default visibility rule that would make this work? I don't care much about 'throw', just about container operations. Yes, I know that containers can throw, but I'm prepared to code defensively to avoid it.

Community
  • 1
  • 1
bmargulies
  • 97,814
  • 39
  • 186
  • 310
  • 3
    Compile everything with the exact same compiler options, compiler version and library version, and it should be fine. This is a compiler-specific question, though, since there is no standard C++ ABI, nor a standardized library implementation. – Kerrek SB Jun 22 '13 at 15:15
  • Not good enough as documented. This isn't the ABI problem, it's the accidental creation of multiple independent pools or other items. – bmargulies Jun 22 '13 at 15:25
  • I suggest to give up sharing STL containers. They are implementation specific at the binary level (i.e. can vary from one compiler to another, or from one compiler version and compiling options to another). And they might be optimized differently ... Maybe you want to use Link Time Optimization.... – Basile Starynkevitch Jun 22 '13 at 15:43
  • Oh, yeah, of course: There's no notion of "shared library" in the standard compilation model, so the notions of global initialization and static storage become problematic. Best to avoid global storage when using dynamic loading and manage your resources explicitly. – Kerrek SB Jun 22 '13 at 15:49
  • There is nothing mysterious in STL containers. No reason in the world why they cannot be shared just like objects of any other class type (provided everything is compiled with the same compiler etc, just like you need to ensure for any other class type). DSOs are objects. It matters not how they are assembled into a finished program, at link time or at program startup time. If you can pass a vector between two objects, you can pass it between two DSOs. – n. m. could be an AI Jun 22 '13 at 18:27
  • Addendum: you need to hide symbols carefully, but this is true whether you share STL containers or not. – n. m. could be an AI Jun 22 '13 at 18:36
  • @n.m. Not so. Some allocators define pools and caches that malfunction across shared lib boundaries due to symbol visibility. GCC does not document these symbols, let alone STLport. – bmargulies Jun 22 '13 at 19:51
  • @bmargulies: can you give an example? I am not aware of any symbol with non-default visibility defined by STL. – n. m. could be an AI Jun 22 '13 at 20:00
  • @n.m. STLport defines a pool allocator, and the current default, as per the links, that things are _not_ visible, causes it to be duplicated. I saw some evidence that the gcc 4.4 STL also does something like this by default, but the original encounter was some years ago. – bmargulies Jun 22 '13 at 20:30
  • I would regard it as a bug in STLport. As for GCC, I have never heard of anything like that. – n. m. could be an AI Jun 22 '13 at 21:42

1 Answers1

0

My google-ability returned to me, and thus I found http://gcc.gnu.org/wiki/Visibility, which I think tells me everything there is to know. It won't tell me about gory internals of STL, but I don't think it has to.

bmargulies
  • 97,814
  • 39
  • 186
  • 310