Ned Deily <> added the comment:

Going back and looking closer at the original failure, I see now that the root 
cause of the configure failures *is* using --with-universal-archs=64-bit.  As 
noted in the Mac/README file, "64-bit" means compile for both "ppc64" and 
"x86_64" architectures; the configure tests fail because the Apple-supplied 
build tools (via Xcode or the Command Line Tools) have not supported either ppc 
or ppc64 for many years (since 10.7, I believe).  In more recent releases prior 
to macOS 10.15 Catalina, macOS still supported running programs in either 
intel-32 (i386) or intel-64 (x86_64) so there was still some use for 
--with-universal-archs=intel, which compiles for both x64_64 and i386.  But 
10.15 Catalina no longer includes 32-bit libraries and frameworks, so it is not 
possible to run 32-bit executables natively anymore.  Thus the only 
architecture option that is of use on 10.15 is the default, x86_64.  So my 
original suggestion, to remove the --enable-universalsdk and 
--with-universal-arch option
 s from your ./configure command should solve the problems you are seeing.  I 
also verified that --enable-optimizations without --wiht-universal-arch and 
--enable-universalsdk resulted in a successful build (after following the 
Devguide's recommendations to install missing libraries using Homebrew).

That said, ./configure should be less cryptic about these kinds of problems.  
I've opened Issue38443 to suggest that ./configure be enhanced to give better 
error messages when a CPU arch is not available to build.

I was unable to reproduce the different failure reported by Bill Minasian in 
msg351312.  If that problem can be reproduced with the stable release of 10.15 
and Xcode 11, please open a new issue for it with details on how to reproduce.


Python tracker <>
Python-bugs-list mailing list

Reply via email to