[MacPorts] #71730: Fails to build Python313 on Sequoia

Sat Jan 4 23:09:04 UTC 2025

#71730: Fails to build Python313 on Sequoia
-------------------------+--------------------
  Reporter:  mouse07410  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:
      Port:  python313   |
-------------------------+--------------------

Comment (by mouse07410):

 > So far as we know, nobody else has this problem anywhere, and googling
 for it shows nothing to me. Python is extensively tested upstream, and by
 many users.

 What about this: https://trac.macports.org/ticket/71738 ? While the ticket
 is rather poorly formed, the problem it indicates is the same. Actually, I
 discovered the problem with python313 that way too - meson failed to
 upgrade. I didn't plan to install python313 at all.

 > does your Xcode match your CLTs? If no, make them match.

 Of course it does. Xcode-16.2 and CLT-16.2. Mind you, the results with and
 without CLT installed are exactly the same - test failure in
 "test_hashlib".

 > is there anything in /usr/local? If so remove it.

 Sorry, that's absolutely impractical - /usr/local houses AFS, HSM (**not**
 SoftHSM), and other similar (necessary for my work) stuff, which Macports
 doesn't provide. One thing I can say about it - it does not collide with
 Macports-installed ports/stuff.

 Also (see below) - removing {{{/usr/local/bin}}} and other "extraneous"
 dirs from the {{{PATH}}} changed nothing (same error/failure).

 > have you selected anything with "port select"? if so disable it all.

 Currently, I've python311, python312, and (now) python313 installed, with
 "port select python python312" Similarly, with GCC and Clang. Are you
 suggesting disabling them all, reverting to MacOS system python and Xcode
 gcc???

 Regardless, I disabled python-related selects:
 {{{
 $ port select python none
 $ port select python3 none
 }}}
 It did not help.

 > have you monkey around with symlinks in your SDKs folder? If so, fix
 them.

 No. (And there was no need.)

 > have you modified any of the builds of any of your ports manuallly --
 forced a compiler, editied a Portfile? If so, undo that.

 Absolutely not. Most of these things are above my competence anyway.

 > have any of the port you installed when you had no CLTs installed been
 installed in an "incorrect" fashion because there were no CLTs? Anything
 that burns in a path to an SDK or compiler setting (PERL, python, etc,
 etc, etc) are suspect.

 Hmm, not sure. It is possible that many of the ports upgraded after this
 machine moved to Sequoia, were built without CLT. But since those ports
 **do** work (e.g., python312, clang-19.1.6, etc.) - why would they be
 suspect?

 > have you set up anything in your PATH besides default MacPorts settings?

 Yes, absolutely! Rust toolchains, Haskell toolchains, Java toolchains,
 quite a few crypto stuff, etc. etc. This machine is for doing stuff
 besides carrying ports...

 **However**, even after I set PATH to
 {{{/opt/local/bin:/usr/bin:/bin:/sbin::}}}, I get the same failure.

 > Are you modifying anything at all in or your .zshrc?

 Nothing really.

 > are you using any non-default options?

 The only non-default options for Macports are:
 - setting Web proxy (otherwise it won't reach the servers);
 - limiting the number of parallel executions to 4 (yes, I have reasons for
 that).

 > Any DEVEL ports? LIBRESSL instead of OPENSSL? Etc etc etc.

 Oh no. None of the above.

 > If ALL of that indicates you have a 100% clean system, then all it can
 come down to after all that is an interaction with some port you have
 installed that most of us would not have installed that is hosing the
 build.

 Sorry, I can't have a "100% clean system", as wouldn't be of any use to
 either me or my employer. Ports get installed on my machine to assist
 doing my work, they don't serve any purpose on their own.

 And yes - it is quite possible that there's a clash with some of the other
 installed ports. I'm attaching the list of the installed ports (turns out,
 the number is 731).

 > I'm completely unfamiliar with python's build system so I can't guide
 you, beyond that it would be somewhere under the work directory.

 Alas, there's nothing related to the tests output in the build directory.
 :-(

 **Addition**

 I decided to try the upstream code - downloaded the source for
 python-3.13.1, and built it. When I turn optimizations on - same error,
 and here are the details:
 {{{
 $ ./python.exe Lib/test/test_hashlib.py
 ..      fetching http://www.pythontest.net/hashlib/blake2b.txt ...
 ..      fetching http://www.pythontest.net/hashlib/blake2s.txt ...
 ..      fetching http://www.pythontest.net/hashlib/sha3_224.txt ...
 ..      fetching http://www.pythontest.net/hashlib/sha3_256.txt ...
 ..      fetching http://www.pythontest.net/hashlib/sha3_384.txt ...
 ..      fetching http://www.pythontest.net/hashlib/sha3_512.txt ...
 .....   fetching http://www.pythontest.net/hashlib/shake_128.txt ...
 .       fetching http://www.pythontest.net/hashlib/shake_256.txt ...
 .............................
 ======================================================================
 ERROR: test_algorithms_available
 (__main__.HashLibTestCase.test_algorithms_available)
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/Users/ur20980/src/Python-3.13.1/Lib/hashlib.py", line 160, in
 __hash_new
     return _hashlib.new(name, data, **kwargs)
            ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
 _hashlib.UnsupportedDigestmodError: [digital envelope routines]
 unsupported

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/Users/ur20980/src/Python-3.13.1/Lib/test/test_hashlib.py", line
 223, in test_algorithms_available
     digest = hashlib.new(name, usedforsecurity=False)
   File "/Users/ur20980/src/Python-3.13.1/Lib/hashlib.py", line 166, in
 __hash_new
     return __get_builtin_constructor(name)(data)
            ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
   File "/Users/ur20980/src/Python-3.13.1/Lib/hashlib.py", line 123, in
 __get_builtin_constructor
     raise ValueError('unsupported hash type ' + name)
 ValueError: unsupported hash type whirlpool

 ----------------------------------------------------------------------
 Ran 78 tests in 9.911s

 FAILED (errors=1, skipped=2)
 }}}
 It seems to be asking for weird unsupported hashes, such as "whirlpool"
 and "md4".

 The above finally gave me the necessary clue.

 **Answer/Solution**

 My (Macports-installed!) OpenSSL-3.4.0 had extra providers that I added,
 including OQS provider, PKCS11 provider, and (drum-roll!) **{{{legacy}}}**
 provider. This provider, apparently, interfered with the {{{hashlib}}}
 test. Disabling it alleviated the problem:
 {{{
 $ openssl list -providers
 Providers:
   default
     name: OpenSSL Default Provider
     version: 3.4.0
     status: active
   oqs
     name: OpenSSL OQS Provider
     version: 0.8.1-dev
     status: active
   pkcs11
     name: PKCS#11 Provider
     version: 3.4.0
     status: active
 $ port -v installed python313
 The following ports are currently installed:
   python313 @3.13.1_0+lto+optimizations (active) requested_variants=''
 platform='darwin 24' archs='arm64' date='2025-01-04T17:54:40-0500'
 $
 }}}

 **Conclusion**

 {{{python313}}} port depends on OpenSSL-3 port, **and** requires that the
 {{{legacy}}} provider is not enabled.

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