[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))) \
__attribute__((availability(watchos,strict,introduced=5.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
std::bad_optional_access::~bad_optional_access()
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?
Best,
Ken
-------------- 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