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

[Ken Cunningham via libcxx-dev]

Thanks, that matches our observations.

Ken

On 2020-06-09, at 11:40 AM, Louis Dionne wrote:

> Thanks for the heads up. I think the availability markup was too stringent.
> 
> commit 7fb40e1569dd66292b647f4501b85517e9247953
> Author: Louis Dionne <ldionne at apple.com>
> Date:   Tue Jun 9 14:08:55 2020 -0400
> 
>     [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.
> 
> Louis
> 
>> On May 31, 2020, at 01:53, Ken Cunningham via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
>> 
>> 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
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
> 

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