Boost logo

Boost :

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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at