Repository navigation
_scproxy and Python Launcher fail to build wtih GNU gcc on macOS 10.13+ #70505
Description
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:
assignee = 'https://github.com/ned-deily'
closed_at = None
created_at = <Date 2016-02-09.04:36:24.611>
labels = ['OS-mac', 'build', '3.9']
title = '_scproxy and Python Launcher fail to build wtih GNU gcc on macOS 10.13+'
updated_at = <Date 2020-05-19.08:11:12.595>
user = 'https://bugs.python.org/RobertPFischer'bugs.python.org fields:
activity = <Date 2020-05-19.08:11:12.595>
actor = 'Arfrever'
assignee = 'ned.deily'
closed = False
closed_date = None
closer = None
components = ['Build', 'macOS']
creation = <Date 2016-02-09.04:36:24.611>
creator = 'Robert P Fischer'
dependencies = []
files = ['41865']
hgrepos = []
issue_num = 26317
keywords = ['patch']
message_count = 27.0
messages = ['259914', '259927', '259929', '260113', '260162', '260194', '260195', '260215', '331768', '342037', '342055', '342081', '342139', '342179', '342432', '359893', '359894', '359922', '359923', '369213', '369218', '369224', '369227', '369246', '369247', '369248', '369325']
nosy_count = 9.0
nosy_names = ['terry.reedy', 'ronaldoussoren', 'vstinner', 'ned.deily', 'Arfrever', 'python-dev', 'Robert P Fischer', 'corona10', 'Jeffrey.Kintscher']
pr_nums = ['13306', '19681', '20176', '20177', '20182']
priority = 'high'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue26317'
versions = ['Python 3.9']
Activity
RobertPFischer commentedon Feb 9, 2016
Changes to OS X 10.11 render GCC's Objective-C compiler useless. However, I want to compile the main part of Python in GCC (because my C++ / Fortran Cython modules use GCC).
I tried to build Python (via MacPorts) using Clang for Objective-C and GCC for C/C++. The environment upon running ./configure included:
CC='/Users/rpfische/macports/mpgompi-4.9.3/bin/gcc-mp-4.9'
CXX='/Users/rpfische/macports/mpgompi-4.9.3/bin/gcc-mp-4.9'
OBJC='/usr/bin/clang'
OBJCXX='/usr/bin/clang++'
HOWEVER... the build still tried to use GCC to compile Objective-C, and failed miserably:
:info:destroot /Users/rpfische/macports/mpgompi-4.9.3/bin/gcc-mp-4.9 -pipe -Os -arch x86_64 -Wno-unused-result -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -o FileSettings.o -c ./FileSettings.m
:info:destroot /usr/include/objc/NSObject.h:22:4: error: unknown type name 'instancetype'
:info:destroot - (instancetype)self;
:info:destroot ^
...
Log file attached.
ronaldoussoren commentedon Feb 9, 2016
The build fails while building the "Python Launcher" application. This is an Objective-C project.
If GCC doesn't support the system headers on OSX 10.11 there's nothing the Python project can do about that.
RobertPFischer commentedon Feb 9, 2016
I'm trying to compile the Objective-C portions of Python (the Python
Launcher app) with clang, not GCC. Why does Python insist on using GCC,
even when I set the OBJC env variable to clang? That seems to be a problem
that the Python project CAN fix.
On Tue, Feb 9, 2016 at 6:39 AM, Ronald Oussoren <report@bugs.python.org>
wrote:
ronaldoussoren commentedon Feb 11, 2016
The makefiles use CC throughout and don't look at and OBJC variable. Is that variable a standard way to specify an ObjC compiler in makefiles?
Make's default ruleset for compiling .m files uses$(CC) and doesn't look at $ (OBJC).
I wouldn't be opposed to a patch that makes it possible to specify an ObjC compiler, could you write such a patch? BTW. The patch should also update the autoconf script (use AC_PROG_OBJC).
RobertPFischer commentedon Feb 12, 2016
I believe that OBJC and OBJCFLAGS are standard for Autoconf/Automake:
https://www.gnu.org/software/automake/manual/html_node/Objective-C-Support.html
https://www.gnu.org/software/autoconf/manual/autoconf-2.61/html_node/Output-Variable-Index.html#Output-Variable-Index
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=using%20objective%20c%20with%20autoconf%20automake
I wouldn't be opposed to a patch that makes it possible to specify an ObjC
Sorry, I don't do Autotools --- a software package that came to us directly
from the seventh level of Hell. CMake's main claim to fame is it's not as
bad.
terryjreedy commentedon Feb 12, 2016
3.4 only gets security fixes
RobertPFischer commentedon Feb 12, 2016
Could this be fixed on 3.5 and 3.6?
On Fri, Feb 12, 2016 at 2:34 PM, Terry J. Reedy <report@bugs.python.org>
wrote:
terryjreedy commentedon Feb 12, 2016
When you reply by email to an email, please snip off the quote, except for possible a line that you are responding to. The disposition of this issue for 3.5+ is up to Ned or Ronald.
terryjreedy commentedon Dec 13, 2018
3.5 is and 3.6 will soon be on security fix only status. Robert, please verify that this is still an issue with 3.7 and the current build files.
websurfer5 commentedon May 10, 2019
This is still an issue with the 3.7 and the master branches. The Objective-C portion of the build still fails with gcc 8.3.0 on OS X Mojave (14.x). Specifying OBJC and OBJC++ on the configure command line does nothing because there is nothing in the script using the options.
24 remaining items
vstinner commentedon May 18, 2020
I tested manually and I confirm that FreeBSD builds again, thanks :-)
Arfrever commentedon May 19, 2020
Also there was FLAFS typo in this line, which is probably not needed at all:
OBJCFLAFS=@OBJCFLAGS@
AC_SUBST(OBJCXX) was added, but there was no usage of @OBJCXX@ anywhere...
erlend-aasland commentedon May 19, 2022
Is this still a valid issue? @corona10?
ned-deily commentedon May 19, 2022
The original PR to add separate OBJC config variables was reverted due to the buildbot failures and was never reapplied. So I expect it is still an issue for those who want to try to build Python on macOS with gcc. It's not something we recommend and is perhaps of even less importance with the introduction of Apple Silicon Macs and their build dependencies on the Apple compiler tool chain. I don't have any immediate plans to pursue it so I'm deassigning myself if someone else wants to jump in.
ned-deily commentedon May 19, 2022
Also, the PR would need to be updated to deal with the subsequent changes to Modules/Setup et al to allow building of _scproxy without Distutils.
erlend-aasland commentedon May 19, 2022
I'm marking it as pending (close). If Dong-hee or anyone else want to pursue this, feel free to remove the label and pick up the loose ends.
erlend-aasland commentedon Jul 20, 2022
No-one has jumped in here. Closing this; feel free to reopen if you disagree.
barracuda156 commentedon Apr 7, 2025
@erlend-aasland @ned-deily It would be nice to have it re-opened. The problem still exists.