Catching derived exceptions types fails on Clang/MacOS X

Question

I have a C++ library which I'm trying to get running on Mac OS X with Clang. The library consists of a DLL and a Unit-Test executable. It compiles fine with GCC and MSVC, with GCC, I use the following settings:

• The library is compiled with -fvisibility=hidden
• All exposed classes are explicitly marked as __attribute__(visibility("default"))
• The library has some exception classes, derived from std::runtime_error. All such classes are marked for default visibility. There is a root class LibraryException from which more specific exceptions are derived.
• On GCC, I use -std=c++0x, with clang, both the library and the unit test executable is built with -stdlib=libc++ -std=c++11

On Mac OS X, the unit test framework now fails, because exceptions are of the wrong type. I.e. a test like this fails:

// bla.foo () throws CustomException, which is derived from LibraryException
TEST_THROWS (bla.foo (), CustomException)

// This works however
TEST_THROWS (bla.foo (), LibraryException)

I verified that the typeinfo and vtable of my custom exception classes is exported using nm -g library.dylib | c++filt -p -i. This seems to be the case for all exceptions ... what the heck is going on here? I have tried to debug on the of the errors, and I see how the correct type is being thrown in the library and yet the same type cannot be caught in the unit test executable. Is there something special required with Clang to get this working? I'm using the latest googletest framework from SVN for testing.

A small test program exhibits the same problem:

try {
    funcThatThrowsCustomExceptionFromLibraryDylib ();
} catch (CustomException& e) {
    // doesn't get here
} catch (LibraryException& e) {
    // does get here
    // after demangle, this prints CustomException
    // Can cast down to CustomException and access the fields as well
    std::cout << typeid (e).name () << "\n";
}

It also fails for instance when a boost::lexical_cast exception is thrown from the Library.

Answer 1

Here is the correct solution:

When applying the visibility attribute, it must be applied both when the library is compiled as well when it is consumed. Otherwise, the client will not see the classes. For boost::lexical_cast, this means you have to use

 #pragma GCC visibility push(default)
 #include <boost/lexical_cast.hpp>
 #pragma GCC visibility pop

until they get it fixed in the library by adding a __attribute((visibility("default"))) to the exception (as of Boost 1.50, the attribute is present, but it seems that the support for Clang is not there yet). When using it in a header in the library, so it can be properly caught in the client code. This #pragma also works with Clang.

The fact that specifying a throw () destructor helped was some luck, but it's definitely not the right fix.