Packages that require new OSX SDKs

[allanleal]

Issue:

We have moved from C++14 to C++17 and there are now a couple of issues when building our library on conda-forge. I'll focus for now on the OSX issue only. When compiling our Python bindings using pybind11, with clang 9.0.0, we get errors with a note as this:

note: 'operator delete' has been explicitly marked unavailable here
_LIBCPP_OVERRIDABLE_FUNC_VIS _LIBCPP_AVAILABILITY_SIZED_NEW_DELETE void  operator delete(void* __p, std::size_t __sz) _NOEXCEPT;

We have already investigated this issue in the web, and we now add the compile options -fno-aligned-allocation -fno-sized-deallocation, which have been enough to solve the exact same issue in our own machines (making sure clang 9.0.0 from conda-forge is used). However, the issue is not resolved with these options when compiling in a conda-forge environment. Full build log available in this Azure link.

@isuruf has pointed out that this is due to an older SDK and a newer one could be provided as a solution.

The full build log (with all env and conda system info) in this text file:

conda-forge-osx-build-log.txt

[isuruf]

It is possible to override this like https://github.com/conda-forge/qt-feedstock/blob/master/recipe/conda_build_config.yaml

Issue is that it is impossible atm to prevent users on older systems installing packages targeting newer ones. We should come up with a strategy as the number of packages needing this is slowly rising. From 1 package (qt) from several months ago to a handful now.

I though about a package like macos_ver that is a dependency of all compiled packages, but conda solver always installs the latest possible version, so this might become confusing.

cc @kalefranz, @mingwandroid, @conda-forge/core, @conda-forge/staged-recipes

[allanleal]

Thanks @isuruf . @tadeu pointed out that this other conda_build_config.yaml, for mesalib, is also a possible solution. Can you comment which one would be more adequate (if this at all matters)?

[beckermr]

Is a virtual package the right choice here?

https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-virtual.html#managing-virtual-packages

[beckermr]

To be clear, we could have one that indicates greater than or equal to 10.12 osx support. Ditto for 10.9.

[isuruf]

Yes. A virtual package seems like the correct approach. I'm sure @kalefranz and @mingwandroid will accept a PR for conda.

[jjhelmus]

For reference, conda/conda#8267 is the PR where the __cuda virtual package was implemented. That was the first (and right now only) virtual package. Hopefully with the framework in place adding more virtual packages will require fewer additions to conda.

[beckermr]

Sounds good. I am backed up on PRs ATM so no promises. :)

[beckermr]

Here is a PR. I need to sign the CLA which will take time with my local lawyers.

conda/conda#9349

[jakirkham]

Also issue ( conda/conda#9348 ) about adding virtual packages to track system C library version may be of interest.

[isuruf]

We need to send PRs to the following feedstocks with run_constrained added as in https://conda-forge.org/docs/maintainer/knowledge_base.html#requiring-newer-macos-sdks

• openmpi
• qt
• pyqt
• nodejs
• javafx-sdk
• reaktoro
• ldas-tools-al
• freecad

cc @conda-forge/openmpi, @conda-forge/qt, @conda-forge/pyqt, @conda-forge/javafx-sdk, @conda-forge/reaktoro, @conda-forge/ldas-tools-al, @conda-forge/freecad, @conda-forge/core