[MacPorts] #62757: py38-gnureadline @8.0.0: error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "11.0" but "11.2" during configure (was: Failed to build py38-gnureadline)

[MacPorts]

#62757: py38-gnureadline @8.0.0: error: $MACOSX_DEPLOYMENT_TARGET mismatch: now
"11.0" but "11.2" during configure
-----------------------------+----------------------
  Reporter:  swaban          |      Owner:  stromnov
      Type:  defect          |     Status:  assigned
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:  2.6.99
Resolution:                  |   Keywords:
      Port:  py-gnureadline  |
-----------------------------+----------------------
Changes (by ryandesign):

 * status:  new => assigned
 * cc: jmroot (added)
 * port:   => py-gnureadline
 * owner:  (none) => stromnov


Comment:

 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/62757#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS