libcxx v18.1.8

[h-vetinari]

Cleaned-up version of #144, based on #154 (will be rebased once that's in)

• Get it to build
• Deal with fallout from llvm/llvm-project@51e91b6
• Decide what to do about libunwind
• Adapt to tzdb support (see llvm/llvm-project@f78f93b)
  • not important for libcxx 18, which has basically zero tzdb functionality; for libcxx 19, use approach from tzdb integration ctng-compilers-feedstock#142
• Enable _LIBCPP_HARDENING_MODE_FAST? #136
• Do something about misdetection of dladdr/pthreads on linux?
  • upstream bug
• Decide about (& implement) Shipping std and std.compat modules #137
  • defer to libcxx 19, which turns this feature non-experimental and ships these files by default.
• Decide what to do (if anything) about losing support for clang<15 -> drop
  • root moved on to clang 16
  • cling is not maintained anymore (quoth @SylvainCorlay)
  • llvmlite still at llvm 14, but that does not conflict with newer clang/libcxx

---

Closes #136
Closes #144
Closes #156

[conda-forge-webservices]

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]

@isuruf, I'd appreciate your input on how to handle libunwind here. At first I thought this might be related to the warning

[1136/1183] Linking CXX shared library lib/libc++.1.0.dylib
x86_64-apple-darwin13.4: warning: argument unused during compilation: '--unwindlib=none' [-Wunused-command-line-argument]

but as it turns out, this is just an artefact of an old CMake work-around (injecting flags to both compiler & linker, instead of only the linker), but backporting that PR makes no difference to the fact that basic tests here fail on both linux & unix without libunwind.so, but pass if we package it.

I don't know if this situation is similar to libcxxabi, but I have to assume it was intentional not to ship libunwind so far? At least the tests (including the downstream ones) pass if it gets packaged, so it doesn't seem to have the same problems as libcxxabi?

If we do ship it, putting it in the libcxx output (as I'm doing here provisionally) is wrong from a layering perspective, as libcxxabi also depends on libunwind (so we'd probably want a separate output?):

WARNING (libcxxabi,lib/libc++abi.so.1.0): lib/libunwind.so.1 not found in any packages
WARNING (libcxxabi,lib/libc++abi.so.1.0): /lib64/libpthread.so.0 not found in packages, sysroot(s) nor the missing_dso_whitelist.
.. is this binary repackaging?
WARNING (libcxxabi,lib/libc++abi.so.1.0): /lib64/libc.so.6 not found in packages, sysroot(s) nor the missing_dso_whitelist.
.. is this binary repackaging?
WARNING (libcxxabi,lib/libc++abi.so.1.0): /lib64/ld-linux-x86-64.so.2 not found in packages, sysroot(s) nor the missing_dso_whitelist.
.. is this binary repackaging?

The fact that the sysroot isn't being found on linux is a separate question/regression, which I'm currently working around (cd27eb9). Feedback on this (and the other points in the OP) is certainly welcome, but the libunwind stuff is the most important to me.

[h-vetinari]

It's also possible that the dependence on libunwind (despite the --unwindlib=none flag) is a regression upstream, but that's hard for me to tell, and in any case, the 18.x series saw it's last release already...

[h-vetinari]

@isuruf, I'd appreciate your input on how to handle libunwind here.

If you have a moment...

[isuruf]

Yeah, we definitely don't want to ship our own libunwind in macOS. Not sure about Linux

[h-vetinari]

Yeah, we definitely don't want to ship our own libunwind in macOS.

Is there a way to test what might go wrong if we did ship it? The current libcxx-testing doesn't fail when we do. The rest should have been fixed by a3a0b87, i.e. doing the same as for libcxxabi. For linux I'm now following that approach (i.e. doing the same as for libcxxabi), and turning it into an output.

[h-vetinari]

@isuruf, could you please review this PR when you have a moment?

[h-vetinari]

@isuruf, I consider this ready for merging now. Please let me know if you have any remaining comments.

[h-vetinari]

Thank you!

[h-vetinari]

Hm, just seeing this on main now:

  "errors": [
    "output linux-64/libunwind-18.1.8-ha4b6fd6_0.conda not allowed for conda-forge/libcxx-feedstock"
  ],

I wasn't aware of https://github.com/conda-forge/libunwind-feedstock, which repackages https://github.com/libunwind/libunwind. I'm not sure if it's possible to build libcxx against the existing libunwind (though they aim at doing the same thing).

Or, if we end up allowing two implementations, we'd probably need a mutex, which sounds a bit like overkill for this?

Any thoughts @conda-forge/libunwind?

[h-vetinari]

OK, I believe I fixed this in #160