libcxx-16.0.6 macos SDK vs min version

[mottelet]

Comment:

Hello,

I installed conda 23.11.0 on macOS x86_64 and all libraries were build against 10.9 sdk, which is fine as usual, but I saw that current libcxx-16.0.6 has

Load command 8
cmd LC_VERSION_MIN_MACOSX
cmdsize 16
version 10.9
sdk 10.14

hence no binaries are able to run on old macs having macOS < 10.14 because, for example, std::align_val_t is only available on macOS 10.13 and newer. I have the following issue when running on a macOS 10.9 machine an application compiled against this libc++:

dyld: Symbol not found: __ZdaPvSt11align_val_t
  Referenced from: /Applications/scilab-macos_fmemopen.app/Contents/bin/../lib/thirdparty/libc++.1.dylib
  Expected in: /usr/lib/libc++abi.dylib
 in /Applications/scilab-macos_fmemopen.app/Contents/bin/../lib/thirdparty/libc++.1.dylib

Why libcxx was not built against 10.9 SDK as other packages ?

I see here : conda-forge/conda-forge.github.io#1844 (comment)
that libcxx 17 has recently dropped support for macOS<10.13 when building the shared libcxx library (I noted this in #110 when the RFC opened).

but it seems to have been already the same for libcxx 16.

setting min macOS version to 10.9 is useless if build is made with newer 10.14 SDK (which masks unavailable features in 10.9)

S.

[h-vetinari]

Hi!

Please post the information required by the issue template, in particular conda list and conda info.

Looking at what symbol is missing, we find:

>llvm-cxxfilt --strip-underscore __ZdaPvSt11align_val_t
operator delete[](void*, std::align_val_t)

so indeed about std::align_val_t. That also shows up in this upstream issue llvm/llvm-project#39701, which got solved in llvm/llvm-project@85bdbbf, and updated in llvm/llvm-project@4722b5d (which confirms your claim about support starting from 10.13)

The SDK version should not matter at runtime, for that only the deployment target version should be relevant (i.e. SDK normally only causes. However, I think there might be a libcxx bug that libcxx/include/__config does not set _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION on osx<=10.13, because that's what determines whether that symbol gets defined & used.

(I guess it would also be possible to mark these symbols as unavailable depending on the deployment target in https://github.com/llvm/llvm-project/blob/main/llvm/lib/Analysis/TargetLibraryInfo.cpp, but it seems like libcxx would own this.)

I'm kind of surprised how late in the lifecycle of this package this bug appear - 16.0 has been live in conda-forge for over a year, but the code in hasn't changed for much longer than that. On the other hand, I'm not that surprised because 10.9 has microscopic usage numbers, and I suspect that much of our claimed support has bitrotted away due to being forced to use newer images by Azure Pipelines.

In any case, 10.9 support is basically dead for a while already (and we're getting close to finally require 10.13), so I'm leaning towards treating this as non-actionable. However, if you want to write a PR targeting the 16.x branch that patches _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION and has a test, I'm happy to review & merge.

[mottelet]

Hello,

Thanks for your reply.

write a PR targeting the 16.x branch that patches _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION and has a test,

I am not that experimented with conda recipes, first, please tell me which file in which project I have to patch.

S.

[h-vetinari]

You can check out this branch, add your patch for _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION on top, and then do git format-patches tags/llvmorg-16.0.6 --no-signature, and add the patches under the patches folder as well as here:

libcxx-feedstock/recipe/meta.yaml

Lines 10 to 19 in fa1d837

	patches:
	- patches/0001-libcxxabi-10.9-compatibility.patch # [osx and x86_64]
	- patches/0002-Support-legacy-standalone-builds.patch
	# See https://lists.llvm.org/pipermail/libcxx-dev/2021-July/001172.html
	- patches/0003-Fix-ABI-compatibility-with-system.patch
	- patches/0004-custom-error-message-for-old-sdk.patch
	# upstream removed fallbacks in case the underlying libc didn't support C11 in
	# https://github.com/llvm/llvm-project/commit/21f73d5826fb5024a27eaacafadfa316f58949c5;
	# however, it seems that the then-required using_if_exists does not work as desired yet
	- patches/0005-Revert-libc-Remove-workaround-for-C11-features-on-co.patch

Almost arbitrary test scripts can be added under recipe and then executed here:

libcxx-feedstock/recipe/meta.yaml

Line 69 in fa1d837

commands:

[h-vetinari]

In the meantime, conda-forge's minimum deployment target has moved on to 10.13. I'm therefore closing this issue, but if you want to try to submit a fix against the 16.x branch, we can still consider it.