Cannot build with `CMAKE_OSX_DEPLOYMENT_TARGET=10.14`

[eschnett]

I am trying to build an updated version of openPMD_api with this build script. Note that openPMD now requires C++17, and requires on macOS the option -mmacosx_version_min=10.14 to enable certain C++17 features in libc++.

I am using the current master branch of Yggdrasil.

This works fine on Linux. On macOS the build fails with undefined symbols:

Undefined symbols for architecture x86_64:
  "__ZNSt19bad_optional_accessD1Ev", referenced from:
      __ZNSt3__127__throw_bad_optional_accessEv in ReadIterations.cpp.o
      __ZNSt3__127__throw_bad_optional_accessEv in Series.cpp.o
      __ZNSt3__127__throw_bad_optional_accessEv in WriteIterations.cpp.o
      __ZNSt3__127__throw_bad_optional_accessEv in JSON.cpp.o
      __ZNSt3__127__throw_bad_optional_accessEv in JSONIOHandlerImpl.cpp.o
      __ZNSt3__127__throw_bad_optional_accessEv in ADIOS2IOHandler.cpp.o
  "__ZTISt18bad_variant_access", referenced from:
      __ZNSt3__126__throw_bad_variant_accessEv in Iteration.cpp.o
      __ZNSt3__126__throw_bad_variant_accessEv in Mesh.cpp.o
      __ZNSt3__126__throw_bad_variant_accessEv in Record.cpp.o
      __ZNSt3__126__throw_bad_variant_accessEv in RecordComponent.cpp.o
      __ZNSt3__126__throw_bad_variant_accessEv in Series.cpp.o
      __ZNSt3__126__throw_bad_variant_accessEv in Attributable.cpp.o
      __ZNSt3__126__throw_bad_variant_accessEv in BaseRecordComponent.cpp.o
      ...

These missing symbols are e.g. vtable for std::bad_optional_access or std::__1::__throw_bad_optional_access(), which should definitely be defined in libc++. I thus think that this might be a problem with the build environment provided by BinaryBuilder and not with my build script, or with openPMD_api's build system.

I tried to look into the libc++ in the BinaryBuilder cross-compilation environment, and found that these libraries are just empty shells, presumably just defining which symbols are exported. Could it be that these export lists are missing the symbols above?

[giordano]

Simply changing CMAKE_OSX_DEPLOYMENT_TARGET won't do much, because we use the 10.12 SDK for x86_64 (and 11.0 for aarch64).

I tried to look into the libc++ in the BinaryBuilder cross-compilation environment, and found that these libraries are just empty shells, presumably just defining which symbols are exported. Could it be that these export lists are missing the symbols above?

No, the error you see is due to fact even though you pretend to use 10.14 SDK, those symbols aren't provided anywhere. The *.tbd stub files are actually what's used when compiling software on macOS natively, you can see that locally with -Wl,-t.

At the moment we don't have a standard way to choose a newer libc/SDK (also because until very recently we didn't have a mechanism to make installation "safe" on the user's side), but for macOS it's actually easy to do it (for glibc it'd be much more complicated), see for example https://github.com/JuliaPackaging/Yggdrasil/blob/38a8c9dd73fae3b39ec76fee0bb96162a1b6f138/C/Coin-OR/SHOT/build_tarballs.jl#L8-L9 and https://github.com/JuliaPackaging/Yggdrasil/blob/38a8c9dd73fae3b39ec76fee0bb96162a1b6f138/C/Coin-OR/SHOT/build_tarballs.jl#L18-L32.

This said, in the not-too-distant future we may finally have a mechanism to select a newer libc/SDK for those packages which require it.

This issue is basically a duplicate of #863, but more specifically on the macOS side.

[eschnett]

Thanks for the pointer; this works.

[giordano]

I was going through the list of issues in Yggdrasil and I found https://github.com/JuliaPackaging/Yggdrasil/issues/3223. I presume the two issues are related in the sense that they both have to do with trying to use newer C++ features on macOS. I'm leaving this comment to link the two issues for future reference.

[Downsite]

Similar to the comment from @giordano , I want to link to issues from Yggdrasil https://github.com/JuliaPackaging/Yggdrasil/issues/7139 https://github.com/JuliaPackaging/Yggdrasil/issues/5851 that do not seem to be fixable with using a newer SDK.