bpo-26317: Build Problem with GCC + Macintosh OS X 10.11 El Capitain #13306
Conversation
command line options so that the MacOSX builds can use the clang compiler for the MacOSX-specific Objective C source files. This allows the GNU compiler to be used to build the rest of the project since some of the Objective C system header files are not compilable with the GNU compiler.
…e can force the use of the OBJC compiler when the CC compiler is different. For example, it allows _scproxy.c to be compiled using the clang compiler while the rest of the project uses the GNU C compiler.
|
Requesting review from @ned-deily @terryjreedy |
|
Thanks for the PR. It looks good in principle but I need to more thoroughly review and test in various configurations before accepting for 3.9. If not before, I will do so during the development sprint in early September. |
|
@ned-deily ;-) small reminder ;-) |
|
I believe configure is a generated file and needs to be regenerated again, as well as updating to current master. |
|
The The |
LGTM with build issue.
But I got another issue with the gcc on mac.
This is out of the scope of this issue.
test test_gdb failed
2 tests failed again:
test_cmath test_gdb
== Tests result: FAILURE then FAILURE ==
397 tests OK.
2 tests failed:
test_cmath test_gdb
21 tests skipped:
test_devpoll test_epoll test_idle test_ioctl test_msilib
test_multiprocessing_fork test_ossaudiodev test_smtpnet test_spwd
test_ssl test_startfile test_tcl test_tix test_tk test_ttk_guionly
test_ttk_textonly test_turtle test_winconsoleio test_winreg
test_winsound test_zipfile64
2 re-run tests:
test_cmath test_gdb
You are right, it is out of scope :). And we would need more information to help with the various test failures and skips. If you want to pursue this, you should probably ask for help on the general Python list or elsewhere. But be aware that we do not normally test building Python with current GNU gcc releases on macOS and generally recommend that you use the latest Apple-supplied compilers from the most-up-to-date Command Line Tools or Xcode release for the version of macOS in use. If you don't really need GNU gcc for building Python, you should be able to override the compiler selection with something like:
|
|
Just a quick question, shouldn't |
This file includes an objective C header from macOS. See python#13306
This file includes an objective C header from macOS. See python#13306
|
@corona10 @ned-deily @terryjreedy just a gentle ping, do you think this can be merged? Fixing this (silent) compile error with GCC on macOS would be wonderful. In the current state without the patch, an install of CPython will be generated but it will just not work, as the |
|
Sorry about the delay. To be honest, we don't really support or test building on macOS with anything other than the latest Apple-provided developer tools for a particular macOS release. There are too many options that won't work and our testing resources are limited so this is a really low priority item. Despite that, I do plan to review, test, and decide on it prior to 3.9.0b1; it's nearing the top of my list :) |
|
No problem and thank you!
If you like, I can provide a short GitHub action script for CI that runs macOS+GCC on PRs and pushes. Have one already in my fork.
|
Please open the sperate issue for this if you want :) |
|
No need. We already build some branches with gcc in the Travis CI. But thanks! |
|
Awesome, do these builds run GCC on macOS or Linux? The former triggers the error when starting the interpreter or e.g. installing setuptools with it.
…On April 23, 2020 1:10:54 AM PDT, Ned Deily ***@***.***> wrote:
No need. We already build some branches with gcc in the Travis CI. But
thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#13306 (comment)
|
|
I checked the Travis-CI scripts and they run GCC on Linux. The exact corner case here is GCC on macOS consuming Objective-C files that are only enabled on Darwin platform builds (not covered yet) :) Just in case, please see: #19681 free testing resources for macOS. |
|
Thanks for all the work on this @websurfer5, the merge update @terryjreedy, and the reviews and comments! With the feature code cutoff for 3.9.0 approaching rapidly, I took the liberty of creating a new PR, #20176, based on this one to avoid any last-minute hangups. The code is unchanged but I did make a few wording changes. |
Add support to the configure script for OBJC and OBJCXX command line options so that the MacOSX builds can use the clang compiler for the MacOSX-specific Objective C source files. This allows the GNU compiler to be used to build the rest of the project since some of the Objective C system header files are not compilable by the GNU compiler.
Also, _scproxy.o is built outside of setup.py so that we can force the use of the OBJC compiler when the CC compiler is different. The Makefile builds _scproxy.o and the setup.py script takes care of using the object file to create the _scproxy module instead of compiling the file itself. This approach is taken because setup.py is designed to use a single compiler for everything. Adding support for a second alternative compiler would require re-plumbing distutils, which is complicated and unnecessary because setup.py allows module definitions to specify object files without any .c source files.
This fixes the PythonLauncher build when CC is set to the GNU C compiler. In this case, OBJC can be set explicitly to "clang", or it can be left out and the configure script will automatically discover the clang compiler as the Objective C compiler. For example, a system that used brew to install the GNU C compiler as gcc-8 can specify CC=gcc-8 and the configure script will discover and use the clang compiler as if OBJC=gcc had been specified on the command line. The same behavior applies to the OBJCXX and CXX options.
https://bugs.python.org/issue26317