bpo-26317: Build Problem with GCC + Macintosh OS X 10.11 El Capitain

[websurfer5]

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

[tonybaloney]

Requesting review from @ned-deily@terryjreedy

[ned-deily]

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.

[matrixise]

@ned-deily ;-) small reminder ;-)

[terryjreedy]

I believe configure is a generated file and needs to be regenerated again, as well as updating to current master.

[terryjreedy]

The configure conflict was simple. Apparently, 'PROFILE_TASK' was added after this PR, which adds OBJ* lines in the same place (in 2 places in the file). My fix was to remove the conflict markers, leaving both new entries, with the OBJ* group first.

The What's New 3.8 fix was to remove the now incorrect new entry for this PR. Such entries should be added by the committer when the PR is otherwise ready to commit. If this is a bugfix, this should not get a What's New entry anyway. In any case, tests are running again.

[corona10]

@terryjreedy

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 

[ned-deily]

@corona10

But I got another issue with the gcc on mac.
This is out of the scope of this issue.

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:

./configure ... CC=clang

[ax3l]

Just a quick question, shouldn't _scproxy.c also be renamed to _scproxy.m? libuv just had the exact same error: libuv/libuv#2808

[ax3l]

@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 _scproxy module is missing.

[ned-deily]

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 :)

[ax3l]

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.

[corona10]

I can provide a short GitHub action script for CI that runs macOS+GCC on PRs

Please open the sperate issue for this if you want :)

[ned-deily]

No need. We already build some branches with gcc in the Travis CI. But thanks!

[ax3l]

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)

[ax3l]

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.

[ned-deily]

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.