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 options 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.