I fixed my problem by using the gcc 4.9 instead. I'm still sort of curious about problems making symbols visible across shared libraries. I'm wondering if this might explain some here-to-for impossible to find causes for obscure test failures. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/BOOST-SYMBOL-VISIBLE-tp4673673p4673677.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.

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/