py38-gnureadline @8.0.0: error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "11.0" but "11.2" during configure

[swaban (Swagato Banerjee)]

Fetching archive for py38-gnureadline
--->  Attempting to fetch py38-gnureadline-8.0.0_0.darwin_20.x86_64.tbz2 from https://packages.macports.org/py38-gnureadline
--->  Attempting to fetch py38-gnureadline-8.0.0_0.darwin_20.x86_64.tbz2 from https://mse.uk.packages.macports.org/py38-gnureadline
--->  Attempting to fetch py38-gnureadline-8.0.0_0.darwin_20.x86_64.tbz2 from https://nue.de.packages.macports.org/py38-gnureadline
--->  Building py38-gnureadline
Error: Failed to build py38-gnureadline: command execution failed
Error: See /opt/local/var/macports/logs/_opt_mports_macports-ports_python_py-gnureadline/py38-gnureadline/main.log for details.

[swaban (Swagato Banerjee)]

/opt/local/var/macports/logs/_opt_mports_macports-ports_python_py-gnureadline/py38-gnureadline/main.log

[ryandesign (Ryan Carsten Schmidt)]

The log says:

error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "11.0" but "11.2" during configure

We've seen this type of mismatch message before. It seems to be a sanity check somewhere in the python module build system. The check is probably a bit overzealous now that Apple has changed the version numbering scheme of macOS and its SDKs as of version 11. Any 11.x deployment target should probably be fine but I guess python doesn't know that yet.

The problem is probably that you now use MacPorts 2.6.99 which has a corrected understanding of macOS 11+ version numbering and therefore sets the deployment target to 11.0 on macOS 11.x, whereas you probably used MacPorts 2.6.4 when you installed python38 (or you received a binary of python38 which was built on our build servers which use MacPorts 2.6.4) which still used pre-macOS 11 version numbering for SDKs and therefore set the deployment target to 11.2 on macOS 11.2.x. The "during configure" part of the error message likely refers to configure time of the python38 port.

The developers of python should probably relax their deployment target checking for macOS 11 and later to only check the first number (11), not the first two numbers (11.0, 11.2). I haven't checked whether they've already done so in their latest code. If they haven't, and if a bug report does not already exist in their issue tracker about it, someone should file one.

Until this problem is fixed, a simple workaround is to rebuild python38 from source on your system using sudo port -ns upgrade --force python38. Since that will be built with MacPorts 2.6.99, it will be built with deployment target 11.0, which will match how you're building py38-gnureadline now. If you upgrade python38 to a new version in the future, and it was built on our build server by MacPorts 2.6.4, that will reintroduce the problem and you'll have to rebuild it from source again.

[ryandesign (Ryan Carsten Schmidt)]

(Assigning to stromnov since he maintains py-gnureadline but this is not a py-gnuradline-specific problem; it's a general python problem, and jmroot maintains some of our python ports.)

[jmroot (Joshua Root)]

​https://github.com/pypa/distutils/commit/7423f0767acf5f8713196c5105ece867ec9e7a55

[jmroot (Joshua Root)]

In ae7839b66f8f6b7eda66bda5585cdc6d33101a9b/macports-ports (master):

python38: update to 3.8.10

Also backport relaxation of distutils' MACOSX_DEPLOYMENT_TARGET check.

Fixes: #62757