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.

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.

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

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

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

3.4 only gets security fixes

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

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.

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.

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.

Module/_scproxy.c compiles cleanly with clang 10.0.0 and fails with GNU gcc 8.3.0. Below is the relevant compiler error:

building '_scproxy' extension
gcc-8 -Wno-unused-result -Wsign-compare -g -Og -Wall -pipe -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I../cpython/Include/internal -I../cpython/Include -IObjects -IPython -I. -I/usr/local/opt/zlib/include -I/usr/local/opt/sqlite/include -I/usr/local/Cellar/ossp-uuid/1.6.2_2/include -I/usr/local/include -I/Users/jeff/sandbox/src/python3.7/cpython/Include -I/Users/jeff/sandbox/src/python3.7/build -c /Users/jeff/sandbox/src/python3.7/cpython/Modules/_scproxy.c -o build/temp.macosx-10.14-x86_64-3.8-pydebug/Users/jeff/sandbox/src/python3.7/cpython/Modules/_scproxy.o
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Security.framework/Headers/AuthSession.h:32,
                 from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Security.framework/Headers/Security.h:42,
                 from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/SystemConfiguration.framework/Headers/SCPreferences.h:35,
                 from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/SystemConfiguration.framework/Headers/SystemConfiguration.h:126,
                 from /Users/jeff/sandbox/src/python3.7/cpython/Modules/_scproxy.c:6:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:7:error: variably modified 'bytes' at file scope
  char bytes[kAuthorizationExternalFormLength];
       ^~~~~
building 'zlib' extension

THe _scproxy.c compile error is a separate issue.  The problem arises in an Apple-supplied include file and there are many reports on the web of clang vs gcc differences like this.  I'm not sure what we could or should do about it other than forcing _scproxy to always be compiled with clang or figure out a way to avoid use of that include file hierarchy.

My mistake was not adding

--enable-framework=${HOME}/sandbox/src/python3.7/inst

to the configure script and then running

make
make install

(I know... read the README file)

gcc 8.3.0 doesn't like the Xcode system headers included by the .m files. I will dig into this now that I am using the proper build steps.

As a side note, I find it counter-intuitive that Mac/Makefile only gets invoked by 'make install' to build the Objective-C source files. IMHO they should be built by "make" and then installed by "make install". Forcing a build and install in one step can be dangerous and accidentally leave the system in an undesirable state when the build process fails with a partial install. Also, --enable-framework should use a subpath of --prefix by default for the framework installation instead of defaulting to /Library/Frameworks regardless of the --prefix setting.

I got it to build PythonLauncher using clang and everything else using gcc 8.3.0 by making a few configure script and makefile changes. Unfortunately, "make install" still fails because a python script that requires the unbuilt _scproxy module crashes. I'll work on fixing that next.

I submitted a pull request that fixes both the PythonLauncher build issue and the _scproxy module build issue. They are related because _scproxy is required to install PythonLauncher.

Any progress?

I met this issue during I compile with gcc9 on my local mac machine.
This issue should be fixed..

The progress was the PR.  I just fixed the merge conflicts, I believe correctly.  Please test and review.

Thanks, Terry. I'll look at it shortly.

New changeset 0da546665075aefbb476e192ed64122d340164f4 by Ned Deily in branch 'master':
bpo-26317: Support OBJC and OBJCXX configure command line variables (GH-20176)
https://github.com/python/cpython/commit/0da546665075aefbb476e192ed64122d340164f4

Thanks everyone for their comments and reviews and a very big thank you to Jeffrey for working through the details and providing a solid PR. The change will appear in the 3.9.0b1 pre-release.

This change broke the Python compilation on FreeBSD:
https://buildbot.python.org/all/#/builders/152/builds/855

Either revert it (and re-apply a fixed change after beta1), or fix it. I suggest to block Python 3.9 beta1 release until it's resolved. I consider that FreeBSD is a supported platform.

Sorry about that! Looking now.

New changeset 951ab58024de9b5a21f0b979cdbea51e1049d781 by Ned Deily in branch 'master':
Revert "bpo-26317: Support OBJC and OBJCXX configure command line variables (GH-20176)" (GH-20182)
https://github.com/python/cpython/commit/951ab58024de9b5a21f0b979cdbea51e1049d781

I'm not sure yet exactly what the problem is but it's almost certainly a difference between GNU make and BSD make and something that needs to be checked on FreeBSD. With the 3.9.0b1 cutoff coming very soon, I likely won't be able to test on FreeBSD before then so I have reverted the change for now. Sigh!

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

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