GeezerVison is showing github.com — _scproxy and Python Launcher fail to build wtih GNU gcc on macOS 10.13+ · Issue #70505 · python/cpython
_scproxy and Python Launcher fail to build wtih GNU gcc on macOS 10.13+ #70505Description
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'] ActivityRobertPFischer commented on Feb 9, 2016 MannequinAuthor More actions 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 commented on 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 commented on Feb 9, 2016 MannequinAuthor More actions 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 <[email protected]>
wrote:
Ronald Oussoren added the comment:
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.
----------
nosy: +ronaldoussoren
Python tracker <[email protected]>
<http://bugs.python.org/issue26317\>
ronaldoussoren commented on 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 commented on Feb 12, 2016 MannequinAuthor More actions terryjreedy commented on Feb 12, 2016 3.4 only gets security fixes RobertPFischer commented on Feb 12, 2016 MannequinAuthor More actions Could this be fixed on 3.5 and 3.6?
On Fri, Feb 12, 2016 at 2:34 PM, Terry J. Reedy <[email protected]>
wrote:
Terry J. Reedy added the comment:
3.4 only gets security fixes
----------
nosy: +terry.reedy
stage: -> needs patch
type: -> compile error
versions: +Python 3.5, Python 3.6 -Python 3.4
Python tracker <[email protected]>
<http://bugs.python.org/issue26317\>
terryjreedy commented on 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 commented on 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 commented on 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. vstinner commented on May 18, 2020 I tested manually and I confirm that FreeBSD builds again, thanks :-) Arfrever commented on 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 commented on May 19, 2022 ned-deily commented on 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. Reacted by Erlend E. Aasland ned-deily commented on 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. Reacted by Erlend E. Aasland erlend-aasland commented on 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 commented on Jul 20, 2022 No-one has jumped in here. Closing this; feel free to reopen if you disagree. barracuda156 commented on Apr 7, 2025
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|