bad_optional_access is now in libc++.dylib on 10.13 -- headers out of date?

Hi all,

On MacPorts we have users with 10.13 systems who want to build c++17-requiring software like mkvtoolnix, and others.

This presently fails on these systems due std:optional::value being listed as unavailable in their libcxx:

currently std::optional::value is marked as unavailable on 10.13 by the __config settings in the libc++ headers:

#  define _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS                             \
     __attribute__((availability(macosx,strict,introduced=10.14)))             \
     __attribute__((availability(ios,strict,introduced=12.0)))                 \
     __attribute__((availability(tvos,strict,introduced=12.0)))                \

however, the symbol seems to have been added to the libc++.dylib on 10.13

$ nm /usr/lib/libc++.1.dylib | grep optional
0000000000014fc6 T __ZNKSt19bad_optional_access4whatEv
0000000000014fe8 T __ZNSt12experimental19bad_optional_accessD0Ev
0000000000014fde T __ZNSt12experimental19bad_optional_accessD1Ev
0000000000014fd4 T __ZNSt12experimental19bad_optional_accessD2Ev
0000000000014faa T __ZNSt19bad_optional_accessD0Ev
0000000000014fa0 T __ZNSt19bad_optional_accessD1Ev
0000000000014f96 T __ZNSt19bad_optional_accessD2Ev
0000000000057750 S __ZTINSt12experimental19bad_optional_accessE
0000000000057790 S __ZTISt19bad_optional_access
0000000000051850 S __ZTSNSt12experimental19bad_optional_accessE
0000000000051880 S __ZTSSt19bad_optional_access
0000000000057720 S __ZTVNSt12experimental19bad_optional_accessE
0000000000057768 S __ZTVSt19bad_optional_access

$ c++filt  __ZNSt19bad_optional_accessD0Ev

and simple test apps do link and run (when built with clang-7.0, that is not so rigorous about excluding std::optional::value



struct Foo { int bar; };

int main() {
Foo foo;
std::optional opt = foo;
opt.value().bar = 42;
std::cout << opt.value().bar << std::endl;

I assume this change in libc++.dylib on 10.13 was recently added in some update and just hadn’t percolated through to the llvm source tree, and I was planning to patch the __config headers we install from libcxx-8.0 and libcxx-9.0 with clang-8.0 and clang-9.0 to allow this.

Is there some other aspect to this issue I might be overlooking?



Thanks for the heads up. I think the availability markup was too stringent.

commit 7fb40e1569dd66292b647f4501b85517e9247953
Author: Louis Dionne <>

[libc++] Fix too stringent availability markup for bad_optional_access

The availability markup for bad_optional_access marked it as being added
in MacOS 10.14 and aligned releases, however it appears to have been added
in Mac OS 10.13 and aligned releases.

LMK if that fixes your issue.


Thanks, that matches our observations.