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

Ken Cunningham via libcxx-dev libcxx-dev at lists.llvm.org
Sat May 30 22:53:52 PDT 2020

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

#include <optional>
#include <iostream>

struct Foo { int bar; };

int main() {
    Foo foo;
    std::optional<Foo> 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?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200530/86027748/attachment.html>

More information about the libcxx-dev mailing list