[MacPorts] #61545: python38 +universal fails to build on Big Sur (Apple Silicon Mac)

[MacPorts]

#61545: python38 +universal fails to build on Big Sur (Apple Silicon Mac)
------------------------------+--------------------------
  Reporter:  Gregory-Gelfond  |      Owner:  (none)
      Type:  defect           |     Status:  new
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:  2.6.4
Resolution:                   |   Keywords:  bigsur arm64
      Port:  python38         |
------------------------------+--------------------------

Comment (by arthurcnorman):

 With icu and python39 building in universal mode thinsg indeed go a lot
 further. So this is a report on what I have got going locally and what I
 seemed toi need to change. None of the changes I have made are in any
 respect deep so I hope that just comments here will help if bnobody has
 prodded these cases otherwise.
 (1) jpag showed checkdum failure on the download for me. When I just made
 a private Portfile wtaht wuoted the checksuims of what did get fetched it
 appeared to build. Note I have not tried USING anything yet - just having
 "port install X +universl" has felt like a triumph.
 (2) kerberos5 - just change to depend on python39 not 38
 (3) create py39-libxml2 as a copy of py38/libxml2. But then
 python/libxml2.c and python/types.c have a bunch of cases where the C code
 goes
    if PyXXX_Check(obj) {
 where parens around the condition seem to be missing. When I inserted
 parens in half a doxen places things compiled!
 (4) xorg-libxcb: change to use pythin39 not 38. Thej LOTS of bits of xorg
 stuff build in universal mode. Hoorah!

 (5) Then ossp-uuid is where I am currently stalled. The starting issue is
 that it uses autoconf does not use automake and that means that the
 autotools support files do not get refreshed very automatically - and its
 config.gues, .sub and various libtool files are there in versions from
 maybe 2008 such that they do not know about aarch64.
 I could copy in config.guess, config.sub and libtool.m4 and could make
 some progress, but right now I have libtool version disagreement woes and
 am muddles about whether this is down to ossp-uuid private copies or
 native mac libtoo vs macports or what. But that package is then a
 precondition that blocks quite a lot more.

 (6) mesa and libexpoy (both wanted by other things) depend on py27-libxml2
 has a build failure from within aetup-py atuff. I do not understand that.

 YOu may be well ahead of me on all of these, so this is just encouragement
 and in case noting easy case and what seems the biggest blocker helps.
 Arthur

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