libcxx v15.0.4

[regro-cf-autotick-bot]

It is very likely that the current package version for this feedstock is out of date.

Checklist before merging this PR:

• Dependencies have been updated if changed: see upstream
• Tests have passed
• Updated license if changed and license_file is packaged

Information about this PR:

1. Feel free to push to the bot's branch to update this PR if needed.
2. The bot will almost always only open one PR per version.
3. The bot will stop issuing PRs if more than 3 version bump PRs generated by the bot are open. If you don't want to package a particular version please close the PR.
4. If you want these PRs to be merged automatically, make an issue with @conda-forge-admin,please add bot automerge in the title and merge the resulting PR. This command will add our bot automerge feature to your feedstock.
5. If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

Closes: #103

Pending Dependency Version Updates

Here is a list of all the pending dependency version updates for this repo. Please double check all dependencies before merging.

Name	Upstream Version	Current Version
libcxx	15.0.4

Dependency Analysis

We couldn't run dependency analysis due to an internal error in the bot. :/ Help is very welcome!

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/autotick-bot/actions/runs/3422937571, please use this URL for debugging.}

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[h-vetinari]

This is still going to need more work, see discussion in #98, in particular this:

Support for standalone builds have been entirely removed from libc++, libc++abi and libunwind. Please use these instructions for building libc++, libc++abi and/or libunwind.

[h-vetinari]

@isuruf regarding your comment in #98:

Can you move this to a single build? We can assess after that is done if it does the same thing we had before.

This now builds, including the downstreams tests. Since I didn't write the old recipe I'm not sure what the intention was with (re-)building libcxx against our own libcxxabi, and so I don't know how to verify that it works as intended.

Beyond that, it looks libcxx is now using C11 features which aren't available in glibc 2.12 (this only appeared when activating the tests, which are removed again now)

In file included from $SRC_DIR/libcxx/test/libcxx/strings/c.strings/version_cuchar.pass.cpp:16:
$SRC_DIR/build/include/c++/v1/cuchar:49:9: error: 'mbstate_t' has not been declared in '::'
   49 | using ::mbstate_t _LIBCPP_USING_IF_EXISTS;
      |         ^~~~~~~~~
$SRC_DIR/build/include/c++/v1/cuchar:52:9: error: 'mbrtoc16' has not been declared in '::'
   52 | using ::mbrtoc16 _LIBCPP_USING_IF_EXISTS;
      |         ^~~~~~~~
$SRC_DIR/build/include/c++/v1/cuchar:53:9: error: 'c16rtomb' has not been declared in '::'
   53 | using ::c16rtomb _LIBCPP_USING_IF_EXISTS;
      |         ^~~~~~~~
$SRC_DIR/build/include/c++/v1/cuchar:54:9: error: 'mbrtoc32' has not been declared in '::'
   54 | using ::mbrtoc32 _LIBCPP_USING_IF_EXISTS;
      |         ^~~~~~~~
$SRC_DIR/build/include/c++/v1/cuchar:55:9: error: 'c32rtomb' has not been declared in '::'
   55 | using ::c32rtomb _LIBCPP_USING_IF_EXISTS;
      |         ^~~~~~~~

e.g. c32rtomb got added in glibc 2.16.

Funnily enough, trying to build with a newer sysroot still fails during our tests with:

libc++abi.so: undefined reference to `memcpy@GLIBC_2.14'

(I presume this is because the sysroot requirement is not propagated well enough). I can raise an discussion on the LLVM discourse about what the glibc lower-bound for libcxx is supposed to be, but I tend to think we should bite the bullet on bumping this (as otherwise, stuff on centos 6 might break at runtime).

That C11 requirement is also hitting us on OSX, where some C11 symbols aren't found:

[...]/bin/../include/c++/v1/cstdlib:135:9: error: no member named 'at_quick_exit' in the global namespace
using ::at_quick_exit _LIBCPP_USING_IF_EXISTS;
      ~~^
[...]/bin/../include/c++/v1/cstdlib:136:9: error: no member named 'quick_exit' in the global namespace
using ::quick_exit _LIBCPP_USING_IF_EXISTS;
      ~~^
2 errors generated.

I don't think we can change this with our usual availability hacks (as it's the C library, not libcxx), but I haven't managed to google which SDK added these functions.

PS. Switching on the upstream test suite crashes on linux, and runs into a known issue on osx (because we don't seem to be picking up their skips).

[h-vetinari]

I don't think we can change this with our usual availability hacks (as it's the C library, not libcxx), but I haven't managed to google which SDK added these functions.

OK, it seems this should work based on llvm/llvm-project@21f73d5, which says:

This change means that trying to use libc++ with an old SDK (or on an
old platform for platforms that ship system headers in /usr/include)
will require a recent Clang that supports the using_if_exists attribute.
When using an older Clang or GCC, the underlying platform has to support
a C11 standard library.

[h-vetinari]

I don't think we can change this with our usual availability hacks (as it's the C library, not libcxx), but I haven't managed to google which SDK added these functions.

OK, it seems this should work based on llvm/llvm-project@21f73d5, which says [...]

@isuruf any input on how to deal with this? This is the last missing piece for LLVM 15.

[h-vetinari]

OK, it seems this should work based on llvm/llvm-project@21f73d5, which says [...]

@isuruf any input on how to deal with this? This is the last missing piece for LLVM 15.

OK, I've dealt with this by fully reverting llvm/llvm-project@21f73d5 in #108.