Skip to content

_scproxy and Python Launcher fail to build wtih GNU gcc on macOS 10.13+ #70505

Closed as not planned
Closed as not planned
_scproxy and Python Launcher fail to build wtih GNU gcc on macOS 10.13+#70505
Labels
OS-macbuildThe build process and cross-build

Description

@RobertPFischer
RobertPFischer
mannequin
opened on Feb 9, 2016
BPO 26317
Nosy @terryjreedy, @ronaldoussoren, @vstinner, @ned-deily, @corona10, @websurfer5
PRs
  • bpo-26317: Build Problem with GCC + Macintosh OS X 10.11 El Capitain #13306
  • bpo-26317: GH Action Test #19681
  • bpo-26317: Support OBJC and OBJCXX configure command line variables #20176
  • bpo-25920: Remove socket.getaddrinfo() lock on macOS #20177
  • Revert "bpo-26317: Support OBJC and OBJCXX configure variables .. " (GH-20176) #20182
    		•
    Files
  • log: Log file from attempt to build Python
    		•

    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

    1. RobertPFischer commented on Feb 9, 2016

      @RobertPFischer
      RobertPFischermannequin
      on Feb 9, 2016
      MannequinAuthor

      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.

    2. RobertPFischer
      added
      buildThe build process and cross-build
      on Feb 9, 2016

    3. ronaldoussoren commented on Feb 9, 2016

      @ronaldoussoren
      ronaldoussoren
      on Feb 9, 2016
      Contributor

      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.

    4. RobertPFischer commented on Feb 9, 2016

      @RobertPFischer
      RobertPFischermannequin
      on Feb 9, 2016
      MannequinAuthor

      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:

      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 <report@bugs.python.org>
      <http://bugs.python.org/issue26317\>

    5. ronaldoussoren commented on Feb 11, 2016

      @ronaldoussoren
      ronaldoussoren
      on Feb 11, 2016
      Contributor

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

    6. ronaldoussoren
      added
      OS-mac
      on Feb 11, 2016

    7. RobertPFischer commented on Feb 12, 2016

      @RobertPFischer
      RobertPFischermannequin
      on Feb 12, 2016
      MannequinAuthor

      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?

      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

      compiler, could you write such a patch? BTW. The patch should also update
      the autoconf script (use AC_PROG_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.

    8. terryjreedy commented on Feb 12, 2016

      @terryjreedy
      terryjreedy
      on Feb 12, 2016
      Member

      3.4 only gets security fixes

    9. terryjreedy
      added
      buildThe build process and cross-build
      on Feb 12, 2016

    10. RobertPFischer commented on Feb 12, 2016

      @RobertPFischer
      RobertPFischermannequin
      on Feb 12, 2016
      MannequinAuthor

      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:

      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 <report@bugs.python.org>
      <http://bugs.python.org/issue26317\>

    11. terryjreedy commented on Feb 12, 2016

      @terryjreedy
      terryjreedy
      on Feb 12, 2016
      Member

      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.

    12. terryjreedy commented on Dec 13, 2018

      @terryjreedy
      terryjreedy
      on Dec 13, 2018
      Member

      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.

    13. terryjreedy
      added
      3.7 (EOL)end of life
      on Dec 13, 2018

    14. websurfer5 commented on May 10, 2019

      @websurfer5
      websurfer5mannequin
      on May 10, 2019
      Mannequin

      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.

    15. websurfer5
      added
      3.8 (EOL)end of life
      on May 10, 2019

    16. 24 remaining items

    17. vstinner commented on May 18, 2020

      @vstinner
      vstinner
      on May 18, 2020
      Member

      I tested manually and I confirm that FreeBSD builds again, thanks :-)

    18. Arfrever commented on May 19, 2020

      @Arfrever
      Arfrevermannequin
      on May 19, 2020
      Mannequin

      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...

    19. ezio-melotti
      transferred this issue fromon Apr 10, 2022

    20. erlend-aasland commented on May 19, 2022

      @erlend-aasland
      erlend-aasland
      on May 19, 2022
      Contributor

      Is this still a valid issue? @corona10?

    21. erlend-aasland
      removed
      3.9 (EOL)end of life
      on May 19, 2022
    22. ned-deily
      removed their assignment
      on May 19, 2022

    23. ned-deily commented on May 19, 2022

      @ned-deily
      ned-deily
      on May 19, 2022
      Member

      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.

    24. ned-deily commented on May 19, 2022

      @ned-deily
      ned-deily
      on May 19, 2022
      Member

      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.

    25. erlend-aasland commented on May 19, 2022

      @erlend-aasland
      erlend-aasland
      on May 19, 2022
      Contributor

      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.

    26. erlend-aasland
      added
      pendingThe issue will be closed if no feedback is provided
      on May 19, 2022

    27. erlend-aasland commented on Jul 20, 2022

      @erlend-aasland
      erlend-aasland
      on Jul 20, 2022
      Contributor

      No-one has jumped in here. Closing this; feel free to reopen if you disagree.

    28. erlend-aasland
      closed this as not plannedon Jul 20, 2022
    29. erlend-aasland
      removed
      pendingThe issue will be closed if no feedback is provided
      on Jul 20, 2022
    30. ned-deily
      marked Mac PythonLauncher cannot be compiled with gcc on modern macOS #132183 as a duplicate of this issue on Apr 7, 2025

    31. barracuda156 commented on Apr 7, 2025

      @barracuda156
      barracuda156
      on Apr 7, 2025

      @erlend-aasland @ned-deily It would be nice to have it re-opened. The problem still exists.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      OS-macbuildThe build process and cross-build

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions