Difficulties configuring LTO on macOS with clang

[Scott Colby]

Hello all,

I am having difficulty building Python with `--with-lto` on macOS 10.14.5. With a clean checkout of the CPython source at the tagged release for 3.7.4, I ran:

$ ./configure --prefix=/opt/python3.7.4 --enable-optimizations --enable-ipv6 --with-lto --with-openssl=$(brew --prefix openssl) CC=clang
checking for git... found
checking build system type... x86_64-apple-darwin18.6.0
checking host system type... x86_64-apple-darwin18.6.0
checking for python3.7... python3.7
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... checking for --without-gcc... no
checking for --with-icc... no
checking for gcc... clang
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether clang accepts -g... yes
checking for clang option to accept ISO C89... none needed
checking how to run the C preprocessor... clang -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for a sed that does not truncate output... /usr/bin/sed
checking for --with-cxx-main=<compiler>... no
checking for clang++... no
configure:

  By default, distutils will build C++ extension modules with "clang++".
  If this is not intended, then set CXX on the configure command line.

checking for the platform triplet based on compiler characteristics... darwin
checking for -Wl,--no-as-needed... no
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for the Android API level... not Android
checking for --with-suffix...
checking for case-insensitive build directory... yes
checking LIBRARY... libpython$(VERSION)$(ABIFLAGS).a
checking LINKCC... $(PURIFY) $(MAINCC)
checking for GNU ld... no
checking for --enable-shared... no
checking for --enable-profiling... no
checking LDLIBRARY... libpython$(VERSION)$(ABIFLAGS).a
checking for ar... ar
checking for readelf... no
checking for a BSD-compatible install... /usr/local/bin/ginstall -c
checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p
checking for --with-pydebug... no
checking for --with-assertions... no
checking for --enable-optimizations... yes
checking for --with-lto... yes
checking target system type... x86_64-apple-darwin18.6.0
checking for -llvm-ar... no
checking for llvm-ar... ''
configure: error: llvm-ar is required for a --with-lto build with clang but could not be found.

If I change the command to `... CC=cc` configuration appears to happen normally.

On my version of macOS, cc is a symlink to clang.

Why is this happening? What should I be doing differently to explicitly specify clang as my compiler?

Thank you,
Scott Colby