New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CPython fails to build modules with LLVM LTO on Mac OS X #65321
Comments
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: on Mac OS: 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 |
What is your clang version? See also issue bpo-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 bpo-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 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 bpo-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 |
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 [ 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': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: