Difficulties configuring LTO on macOS with clang

2019-07-09 Thread 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=... 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
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Difficulties configuring LTO on macOS with clang

2019-07-10 Thread Scott Colby
Unfortunately that path is absent on my system. Could the issue be that the 
llvm version of ar is not present at all on macOS? What remains confusing in 
that case is that by using CC=cc (and I assume just ar) the LTO compilation 
succeeds, despite cc being a symlink to clang anyway.

Thanks,
Scott

On Tue, Jul 9, 2019, at 15:39, Barry Scott wrote:
> 
> 
> > On 9 Jul 2019, at 19:28, Scott Colby  wrote:
> > 
> > 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=... 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.
> 
> I see /opt/local/bin/llvm-ar-mp-4.0 which ends up running the llvm-ar from 
> /opt/local/libexec/llvm-4.0/bin
> 
> Just a guess but maybe you need to add /opt/local/libexec/llvm-4.0/bin/ to 
> your path
> as its where llvm-ar is.
> 
> Barry
> 
> > 
> > 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
> > -- 
> > https://mail.python.org/mailman/listinfo/python-list
> > 
> 
> 
-- 
https://mail.python.org/mailman/listinfo/python-list