How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages

[Jeroen Demeyer]

Hello,

While working on cysignals, I encounted an issue with
$MACOSX_DEPLOYMENT_TARGET. I have a fix, but I don't know if it's good.
It's not specific to Sage, but it will affect Sage since cysignals is a
Sage package.

For cysignals, I'd really like to use MACOSX_DEPLOYMENT_TARGET >= 10.9
since that enables the C++ <atomic> header (*) which is needed to fix
Sage ticket #24288. The tricky part is that not only cysignals itself
should be compiled with MACOSX_DEPLOYMENT_TARGET >= 10.9 but also every
package using cysignals.

I have a solution which adds the command-line flag
-mmacosx-version-min=10.9 when compiling cysignals:
https://github.com/sagemath/cysignals/commit/17062a64bf5672375982cf295ed93b346b55d680
Thanks to Cython magic, this flag will be passed on to every package
that cimports cysignals.

This solution seems to work and passes CI tests. These tests are done
using Conda, which uses a Python compiled with
MACOSX_DEPLOYMENT_TARGET=10.6, which is then used for every Python
package (analogous to CFLAGS, distutils uses the value for
MACOSX_DEPLOYMENT_TARGET which was used to compile Python).

So my question is basically: what could possibly go wrong? One thing
which worries me is that the command-line flag -mmacosx-version-min=10.9
overrides the environment variable MACOSX_DEPLOYMENT_TARGET. So if
somebody really wanted a higher value for MACOSX_DEPLOYMENT_TARGET than
10.9, it wouldn't work. But I see no solution for this.


Jeroen.


(*) For some reason, the analogous C header <stdatomic.h> works
regardless of MACOSX_DEPLOYMENT_TARGET. Unfortunately, this header is
not compatible with C++, so I really need <atomic>.

[Dima Pasechnik]

I gather openblas has moved to 10.8 from 10.6, see
https://github.com/xianyi/OpenBLAS/issues/1580

Realistically, 10.9 is OK too, I don't think it's actually possible to
build current Sage on anything older than 10.11 or so...

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Samuel Lelievre]

Fri 2019-03-08 11:21:09 UTC+1, Dima Pasechnik:

>
> I gather openblas has moved to 10.8 from 10.6, see
> https://github.com/xianyi/OpenBLAS/issues/1580
>
> Realistically, 10.9 is OK too, I don't think it's actually possible to
> build current Sage on anything older than 10.11 or so...

Current Sage actually builds perfectly fine on older macOS,
in particular macOS 10.10.5 "Yosemite".

Of course, Apple no longer supports Yosemite, so it gets
no security upgrades and is therefore quite vulnerable,
so anyone using that or older is advised to upgrade...

Which reminds me we should really update the wiki page

where we list our supported platforms:

    https://wiki.sagemath.org/SupportedPlatforms

There is a link to that page from the documentation;

I no longer dare to include that link in the new version

announcements sent to sage-announce.

[Jeroen Demeyer]

On 2019-03-08 10:42, Jeroen Demeyer wrote:
> (*) For some reason, the analogous C header <stdatomic.h> works
> regardless of MACOSX_DEPLOYMENT_TARGET. Unfortunately, this header is
> not compatible with C++, so I really need <atomic>.

I just realized that I tried this only with g++ on Linux. With clang++
on OS X, <stdatomic.h> does work. So this avoids needing to mess with
MACOSX_DEPLOYMENT_TARGET.

I'll also try g++ on OS X (do we still support that actually?).

[Dima Pasechnik]

no, I don't think it works since OSX 10.12 or even earlier---due to
changes in Apple's header files you'd need the compiler to know about
"blocks", at least for some spkgs.

[Volker Braun]

You only need MACOSX_DEPLOYMENT_TARGET / -mmacosx-version-min when building binaries to run on older mac versions. Whoever distributes cysignals should decide which min sdk version they support. What is bound to go wrong is that somebody builds an application that includes your library with their chosen MACOSX_DEPLOYMENT_TARGET, and the binaries don't work because some dependency thought it would be fun to require a higher version. And the distributor of the app (like Sage) typically doesn't have a basement full of old macs to test if the binaries really are downward compatible.

* If you definitely require <atomic> then just include it. Add a comment with the min sdk version for anyone hitting that #include error.

* If <atomic> is optional then add a #warning that it is recommended

[Jeroen Demeyer]

On 2019-03-08 19:18, Volker Braun wrote:
> * If <atomic> is optional then add a #warning that it is recommended

Yes, it's optional but the hard part is figuring out whether it's
supported or not.