homepage

CPython fails to build with LLVM's link-time optimization (LTO) in Mac OS. Very similar commands work on Linux.
I'm currently configuring CPython as follows:
on Linux:
RANLIB="ar -s --plugin=/path/to/llvm/lib/LLVMgold.so" CC=/path/to/llvm/bin/clang CXX=/path/to/llvm/bin/clang++ CFLAGS="-g -flto" LDFLAGS="-flto" ./configure
on Mac OS:
CC=/path/to/llvm/bin/clang CXX=/path/to/llvm/bin/clang++ CFLAGS="-g -flto" LDFLAGS="-flto" ./configure
The RANLIB variable should not be needed on Mac, because its toolchain does not need a GOLD plugin.
On Linux, the above builds correctly and passes most of the test suite. On Mac, I receive the following error (similar for other extensions):
building '_scproxy' extension
/usr/bin/clang -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g -flto -I../cpython/Include -I. -I/usr/local/include -I../cpython/Include -I../cpython-lto-build -c ../cpython/Modules/_scproxy.c -o build/temp.macosx-10.9-x86_64-3.5/path/to/cpython/Modules/_scproxy.o
/usr/bin/clang -bundle -undefined dynamic_lookup -flto build/temp.macosx-10.9-x86_64-3.5/path/to/cpython/Modules/_scproxy.o -L/usr/local/lib -o build/lib.macosx-10.9-x86_64-3.5/_scproxy.so -framework SystemConfiguration -framework CoreFoundation
*** WARNING: renaming "_scproxy" since importing it failed: dlopen(build/lib.macosx-10.9-x86_64-3.5/_scproxy.so, 2): Symbol not found: __Py_NoneStruct
 Referenced from: build/lib.macosx-10.9-x86_64-3.5/_scproxy.so
 Expected in: flat namespace
 in build/lib.macosx-10.9-x86_64-3.5/_scproxy.so

What is your clang version? See also issue #20767.

I am indeed using Clang 3.4 (both the one that ships with Mac OS, and a version compiled from the sources).
However, the errors I get are rather different than #20767. In particular, Clang finishes successfully and does produce shared object files; they just don't seem to be loadable.

Just as an experiment (using the 3.4 branch and the Xcode 5.1 clang), the list of unique symbols not found during the test dlopen in setup.py when using -flto:
 _PyArg_ParseTuple
 _PyArg_ParseTupleAndKeywords
 _PyBaseObject_Type
 _PyBool_Type
 _PyByteArray_Type
 _PyBytes_Type
 _PyCFunction_Type
 _PyExc_AssertionError
 _PyExc_BufferError
 _PyExc_EOFError
 _PyExc_IndexError
 _PyExc_IOError
 _PyExc_KeyError
 _PyExc_LookupError
 _PyExc_MemoryError
 _PyExc_NotImplementedError
 _PyExc_OSError
 _PyExc_OverflowError
 _PyExc_RuntimeError
 _PyExc_TypeError
 _PyExc_ValueError
 _PyModule_Create2
 __Py_NoneStruct
Anyone see a pattern there? 
Do we know if anyone has tried to use LTO with a Python build previously? I've never tried it myself and there certainly could be ld and/or dyld differences on OS X. Also, some thought would need to go into and tests developed to see what the performance trade-offs are. For example, I could imagine that LTO might be have more impact if the standard library extension modules were statically linked, e.g. via Modules/Setup*. And there are at least three separate current build configurations to consider on OS X: unshared, --enable-shared, --enable-framework. One would need to look at things like what effect these all have on memory and shared memory footprints as well as cpu resources and real time, with and without LTO and/or other optimizations. It certainly would be an interesting project for someone with the interest and time.
Potentially supporting LTO seems to me to be more of a feature than a bug so I think should be considered a 3.5 issue, at least initially.

Thanks Ned, this is interesting!
I don't know about Mac OS, but on Ubuntu, LTO and PGO apparently make Python around 10% faster (see #17781). However, that data point refers to GCC's LTO, not LLVM's.
Personally I'm interested in LTO because I want to obtain whole-program LLVM bitcode files (for use in a research project about instrumentation). However, if there is something I can help (e.g., running benchmarks with different compilation settings), let me know.

I've used -O4 for extensions in the past (which until recently implied LTO) and that worked fine. 
I'm pretty sure that I haven't used LTO for python itself, apart from a some tests with an early version llvm-gcc where using LTO for building python used to crash the compiler :-)
BTW. There's no clear pattern in the missing symbols. The missing symbols for global functions could be due to aggressive inlining (and then deciding that the standalone function isn't needed anymore), but that is fairly unlikely and wouldn't explain the missing data symbols.

Have you tried the -export_dynamic option for ld(1):
-export_dynamic
 Preserves all global symbols in main executables during LTO. Without this option, Link Time Optimization is allowed to inline and remove global functions. This
 option is used when a main executable may load a plug-in which requires certain symbols from the main executable.

This works for me (with a separate build directory):
 CC=clang CXX=clang++ CFLAGS="-g -flto" LDFLAGS="-flto -Wl,-export_dynamic" ../configure
This is on OSX 10.9.2, with Xcode 5.1, and clang --version says:
$ clang --version
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
Tests are still running, but so far there are no unexpected failures.

I confirm that this also works with my self-compiled Clang 3.4. -export_dynamic was the missing option.
Is a good place to document this?
Otherwise, I think this issue can be closed. Thanks a lot for the help!

No response for a while, and problem solved... closing.

Here is a patch to turn on `-Wl,-export_dynamic` when building with LTO. Unfortunately I have a bunch of tests that fail when running with LTO+PGO of the form of:
[ 95/398] test_bytes
Traceback (most recent call last):
 File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/runpy.py", line 193, in _run_module_as_main
 "__main__", mod_spec)
 File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/runpy.py", line 85, in _run_code
 exec(code, run_globals)
 File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/test/__main__.py", line 3, in <module>
 regrtest.main_in_temp_cwd()
 File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/test/regrtest.py", line 1593, in main_in_temp_cwd
 main()
 File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/test/regrtest.py", line 756, in main
 raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_bytes: Exit code -6

New changeset cc5f8179a7ba by Ned Deily in branch 'default':
Issue #21122: Fix LTO builds on OS X.
https://hg.python.org/cpython/rev/cc5f8179a7ba