libc++ missing symbols for bad_optional_access()

[madscientist]

I don't know what, if anything, can be done about this but if you build on OS X with clang from Apple LLVM 7.3.0 (which comes with Xcode 7.3.1) and you use the experimental/optional header that comes with clang, then you'll get undefined symbol errors at link time if you use the optional::value() method (which needs to throw on bad references) ... here CppUtilTest.cpp is a test program I wrote to verify some local templates that use optional<>.

Undefined symbols for architecture x86_64:
  "std::experimental::bad_optional_access::~bad_optional_access()", referenced from:
/**
      CppUtilLookupTests_lookupStdFind_Test::TestBody() in CppUtilTest.cpp.o
      CppUtilLookupTests_lookupSpecialFind_Test::TestBody() in CppUtilTest.cpp.o
  "typeinfo for std::experimental::bad_optional_access", referenced from:
      CppUtilLookupTests_lookupStdFind_Test::TestBody() in CppUtilTest.cpp.o
      CppUtilLookupTests_lookupSpecialFind_Test::TestBody() in CppUtilTest.cpp.o
  "vtable for std::experimental::bad_optional_access", referenced from:
      CppUtilLookupTests_lookupStdFind_Test::TestBody() in CppUtilTest.cpp.o
      CppUtilLookupTests_lookupSpecialFind_Test::TestBody() in CppUtilTest.cpp.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture x86_64

I had to either go back to using the replacement optional.hpp from here, or else add this to my implementation (in the right namespace)

    bad_optional_access::~bad_optional_access() _NOEXCEPT = default;

Not sure what, if anything, can be done about this because I'm not sure if there's any reliable way to test for it being missing.

[tcbrindle]

Yeah, this is a bug with AppleClang -- for some reason they removed the runtime parts of std::experimental::bad_optional_access from their version of LLVM in 7.3 but kept the header.

I think the best thing to do would be to "blacklist" std::experimental::optional when using AppleClang 7.3, that is, #define STX_NO_STD_OPTIONAL if we detect this compiler version. I'll have a look and see if I can find the right combination of preprocessor defines to reliably detect it.

[tcbrindle]

Hmmm, this is a bit of a headache. It turns out I was wrong, and this isn't fixed in XCode 8. Furthermore, it looks like it occurs even if using upstream LLVM 3.7 or 3.8 on Mac OS (at least, the versions available via Homebrew). I'm not sure about LLVM on Linux or Windows.

The best idea I have for now is to #define STX_NO_STD_OPTIONAL when using libc++ <= 3.8 on an Apple system. If it's still not fixed when LLVM 3.9 is released then we'll have to add that to the blacklist too.

This sucks.

[madscientist]

Yes, very annoying... :-(

[tcbrindle]

The above commit forces STX_NO_STD_OPTIONAL when using libc++ <= 3.8 on Apple systems. This will need to be revisited when LLVM 3.9 is released, but I think this is probably the best we can do for now.

Would you mind giving it a check and seeing whether it works correctly for you?