Re: [boost] BOOST_SYMBOL_VISIBLE

Subject: Re: [boost] BOOST_SYMBOL_VISIBLE
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-23 12:48:14

On 22 Mar 2015 at 13:31, Robert Ramey wrote:

> I'm trying to get my MAC OS (Yosemite) to build the boost serialization
> library and I've having a problem.  In a couple of tests, the program throws
> some exceptions.  When this occurs I get a message something like "terminate
> called after throwing an instance of 'boost::archive::archive_exception'". 
> [snip]
> This doesn't change anything so it looks like I'm barking up the wrong tree. 
> Is there anyone here who might want to shed some light on this?

I as the person who originally added symbol hiding to GCC am as much 
to blame as anybody.

Back in the day when I originally patched GCC with this stuff, I very 
liberally sploshed default visibility over everything (vtables, 
typeinfo etc). That caused problems with template specialised 
visibility whereby one can metaprogram visibility, so they ended up 
paring down my code instead of banning the practice, as I would have 
preferred (I only cared about Windows __declspec equivalance, and I 
still only do, and I suspect so does 99.99% of everybody else).

That resulted in a problem where if base class visibility did not 
match derived class visibility then you got two copies of the base 
class typeinfo generated, and the catch(...) implementation 
historically used to only compare typeinfo pointers, not their 
contents. That got fixed by changing GCC to always compare typeinfo 
strings, so throwing and catching exceptions became much slower. LLVM 
chose to keep exception types not being matched. What really *should* 
have happened is that std::exception and all the STL exceptions must 
always have default visibility, and indeed it normally does in most 
implementations. I personally would have preferred if the compiler 
permanently marked default visibility on any type, or relation 
thereof, ever thrown or caught. But the ship sailed on that too.

Anyway, what you're facing here are some compiler implementation 
inconsistencies, probably caused by the virtual inheritance which was 
always not a regularly tested code path for symbol visibility and 
exception unwinding. A huge problem with ELF visibility is that it is 
sticky to hidden, so you need just one hidden declaration anywhere in 
any of the shared objects loaded by the process (including 
dynamically loaded ones) and it'll hide the symbol for everybody 
irrespective of declarations anywhere else (I tried getting GNU ld to 
issue a warning when visibilities mismatch, and it got closed as 
wontfix). I personally would recommend you drop the virtual 
inheritance and your problems will go away, but if as I assume you 
can't, if on C++ 11 try catching all and using intrusive inspection 
of exception_ptr for your STL to do the type matching by hand, in 
particular do strcmp of the typeinfo strings.

ELF is a steaming dog turd of a binary format, and its many design 
flaws cost millions of wasted programmer hours. I would just *love* 
if it got killed off as soon as humanly possible, but there is zero 
consensus nor funding available for a replacement. That said, your 
problems appear to be on Mac which is Mach O binaries, and I never 
found those to be anything like as problematic, old as they are.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/