FSF gcc48 fails to compile projects on El Capitan due to OS X SDK bug in Availability.h

[jasonw@…]

OS: 10.11 Beta (15A234d) [El Capitan, Public Beta 3]

Xcode: Version 7.0 beta 4 (7A165t)

As a dependency of R, gcc48 failed to build thusly:

--->  Computing dependencies for R
--->  Dependencies to be installed: gcc48
--->  Fetching archive for gcc48
--->  Attempting to fetch gcc48-4.8.5_0.darwin_15.x86_64.tbz2 from http://packages.macports.org/gcc48
--->  Attempting to fetch gcc48-4.8.5_0.darwin_15.x86_64.tbz2 from http://lil.fr.packages.macports.org/gcc48
--->  Attempting to fetch gcc48-4.8.5_0.darwin_15.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/gcc48
--->  Fetching distfiles for gcc48
--->  Verifying checksums for gcc48
--->  Extracting gcc48
--->  Applying patches to gcc48
--->  Configuring gcc48
--->  Building gcc48
Error: org.macports.build for port gcc48 returned: command execution failed
Error: Failed to install gcc48
Please see the log file for port gcc48 for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc48/gcc48/main.log
Error: The following dependencies were not installed: gcc48
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port R failed

Excerpt from log:

:info:build In file included from /usr/include/stdlib.h:61:0,
:info:build                  from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc48/gcc48/work/gcc-4.8.5/libsanitizer/sanitizer_common/sanitizer_allocator.cc:22:
:info:build /usr/include/Availability.h:219:22: error: missing binary operator before token "("
:info:build    #if __has_attribute(availability)
:info:build                       ^
:info:build /usr/include/Availability.h:241:22: error: missing binary operator before token "("
:info:build    #if __has_attribute(availability)
:info:build                       ^

The indicated line in Availability.h is in a section that is new for 10.11.

[Ionic (Mihai Moldovan)]

Please remember to CC the maintainer(s) next time, if any.

[jasonw@…]

I can confirm the same error after updating to the latest public beta:

OS: 10.11 Beta (15A243d) [El Capitan, Public Beta 4]

Xcode: Version 7.0 beta 5 (7A176x)

[macports@…]

I'm getting the same error on OS X 10.11 Beta (15A243d), Xcode 7.0 beta 5 (7A176x)

[jasonw@…]

Same results with public beta 5:

OS: 10.11 Beta (15A262e) [El Capitan, Public Beta 5]

Xcode: Version 7.0 beta 6 (7A192o)

[jasonw@…]

Same results with GM seed:

OS: 10.11 (15A282a) [El Capitan, GM seed]

Xcode: Version 7.0 (7A218)

[ljenkins@…]

I can reconfirm the problem building gcc48 on latest El Capitan GM and latest Xcode:

> System Version:	OS X 10.11 (15A282a)
> Kernel Version:	Darwin 15.0.0
> XCode:                Version 7.0 (7A220)

:info:build In file included from /usr/include/stdlib.h:61:0,
:info:build                  from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc48/gcc48/work/gcc-4.8.5/libsanitizer/sanitizer_common/sanitizer_allocator.cc:22:
:info:build /usr/include/Availability.h:219:22: error: missing binary operator before token "("
:info:build    #if __has_attribute(availability)
:info:build                       ^
:info:build /usr/include/Availability.h:241:22: error: missing binary operator before token "("
:info:build    #if __has_attribute(availability)
:info:build                       ^
:info:build In file included from /usr/include/stdlib.h:61:0,
:info:build                  from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc48/gcc48/work/gcc-4.8.5/libsanitizer/sanitizer_common/sanitizer_symbolizer_itanium.cc:15:
:info:build /usr/include/Availability.h:219:22: error: missing binary operator before token "("
:info:build    #if __has_attribute(availability)
:info:build                       ^
:info:build /usr/include/Availability.h:241:22: error: missing binary operator before token "("
:info:build    #if __has_attribute(availability)
:info:build                       ^
:info:build make[4]: *** [sanitizer_allocator.lo] Error 1
:info:build make[4]: *** Waiting for unfinished jobs....
:info:build make[4]: *** [sanitizer_symbolizer_itanium.lo] Error 1
:info:build make[4]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc48/gcc48/work/build/x86_64-apple-darwin15/libsanitizer/sanitizer_common'
:info:build make[3]: *** [all-recursive] Error 1
:info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc48/gcc48/work/build/x86_64-apple-darwin15/libsanitizer'
:info:build make[2]: *** [all-stage1-target-libsanitizer] Error 2
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc48/gcc48/work/build'
:info:build make[1]: *** [stage1-bubble] Error 2
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc48/gcc48/work/build'
:info:build make: *** [bootstrap] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc48/gcc48/work/build'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc48/gcc48/work/build" && /usr/bin/make -j8 -w bootstrap 
:info:build Exit code: 2
:error:build org.macports.build for port gcc48 returned: command execution failed

[ryandesign (Ryan Carsten Schmidt)]

As a workaround, try installing gcc49, gcc5 or gcc6?

[iqgrande]

Cc Me!

[mv@…]

Cc Me!

[jasonw@…]

Replying to ryandesign@…:

As a workaround, try installing gcc49, gcc5 or gcc6?

FYI, I came across this error when trying to compile R, for which gcc48 is a dependency.

For now, I've worked around this problem by installing R from a binary package :(

[mvenkadesan (MV)]

Replying to jasonw@…:

Replying to ryandesign@…:

As a workaround, try installing gcc49, gcc5 or gcc6?

FYI, I came across this error when trying to compile R, for which gcc48 is a dependency.

For now, I've worked around this problem by installing R from a binary package :(

Uninstalling R, and doing a clean before installing the gcc49 variant fixed it for me.

sudo port uninstall R
sudo port clean --all R
sudo port install R +gfortran49

[jasonw@…]

Replying to m.venkadesan@…:

Uninstalling R, and doing a clean before installing the gcc49 variant fixed it for me.

sudo port uninstall R
sudo port clean --all R
sudo port install R +gfortran49

Cool! Thanks!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #49068.

[billygr (billy)]

Cc Me!

[matt_langston@…]

I'm having the same issue with El Capitan GM (10.11 15A284) and Xcode 7 (7.0.1 build version 7A1001). I can't use the gcc49 workaround because I need the OpenBLAS port which has a recursive dependency on gcc48 via dragonegg-3.4-gcc-4.8.

[jedbrubaker@…]

Cc me!

[vaccari@…]

Cc Me!

[epaell]

Cc Me!

[michelle.lynn.gill@…]

Cc Me!

[alan.mock@…]

Cc Me!

[fracai]

Cc Me!

[glen@…]

Cc Me!

[joaogeada (Joao Geada)]

Cc Me!

[MoogHub]

Patch that adds additional fixes to fixincludes.

[MoogHub]

Hi,

had some time to spare and worked on a patch (see: define_non_standard_clang_macros.patch). This patch works for me, but fixing the actual bug in /usr/include/Availability.h itself would be the best solution.

I'm not sure if I'm correct, but this error is probably caused by some incorrectly defined conditions in /usr/include/Availability.h:

/* for use marking APIs available info for Mac OSX */
#if defined(__has_feature)
  #if __has_attribute(availability)
    #define __OSX_UNAVAILABLE                    __OS_AVAILABILITY(macosx,unavailable)
    #define __OSX_AVAILABLE(_vers)               __OS_AVAILABILITY(macosx,introduced=_vers)
    #define __OSX_DEPRECATED(_start, _dep, _msg) __OSX_AVAILABLE(_start) __OS_AVAILABILITY_MSG(macosx,deprecated=_dep,_msg)
  #endif
#endif

The first condition should be #if defined(__has_attribute) instead of #if defined(__has_feature). This patch will also add more fixes to GCC's fixincludes/inclhack.def and fixincludes/fixincl.x. Most of them might not be directly related to this bug, but they're related to clang's __has_attribute macro.

[matteo.tommasini@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to dar1985.lukic@…:

had some time to spare and worked on a patch (see: define_nonstandard_clang_macros.patch). This patch works for me, but fixing the actual bug in /usr/include/Availability.h itself would be the best solution.

Thanks. If you believe there is a bug in /usr/include/Availability.h, you should ​report it to Apple.

[MoogHub]

Replying to ryandesign@…:

Replying to dar1985.lukic@…:

had some time to spare and worked on a patch (see: define_nonstandard_clang_macros.patch). This patch works for me, but fixing the actual bug in /usr/include/Availability.h itself would be the best solution.

Thanks. If you believe there is a bug in /usr/include/Availability.h, you should ​report it to Apple.

I've already sent a bug-report, but I'm not sure how this is going to be received or if it's a duplication ... apple's bug-tracker is surprisingly disclosed :-/

[kurtjaeke@…]

Cc Me!

[xuod (Cyrille Doux)]

Cc Me!

The patch works for me ! Thanks a lot !

[skymoo (Adam Mercer)]

Cc Me!

[redwoodtree@…]

Cc Me!

[hapaguy (Brian Kurt Fujikawa)]

Cc Me!

[maehne (Torsten Maehne)]

Cc Me!

[grant.jenks@…]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, this is a bug in Availability.h. I've passed it along. Had someone pointed me to this ticket or actually filed a radar months ago, this might have been fixed =/

[jeremyhu (Jeremy Huddleston Sequoia)]

Cc Me!

[arthur.michaut@…]

Cc Me!

[arthur.michaut@…]

same bug for me while I was trying to install py27-scipy

[arthur.michaut@…]

Ok, so we have to wait for the Apple update? Or if I want to apply the patch I just copy paste it in Availability.h? Thanks for your help

[jeremyhu (Jeremy Huddleston Sequoia)]

Yes. If you want, you can just manually edit Availability.h to replace the 'defined(__has_feature)' with 'defined(__has_attribute)' for the OSX and iOS availability macros, but you do so at your own risk because you know what you're doing ;)

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #49381.

[arunava.mukherjee@…]

Cc Me!

[zhangdai1992@…]

Cc Me!

[arthur.michaut@…]

Cc Me!

[arunava.mukherjee@…]

Cc Me!

[arunava.mukherjee@…]

Cc Me!

[murrayeisenberg@…]

Replying to jeremyhu@…:

Yes. If you want, you can just manually edit Availability.h to replace the 'defined(__has_feature)' with 'defined(__has_attribute)' for the OSX and iOS availability macros, but you do so at your own risk because you know what you're doing ;)

Even using sudo with an admin account on OS X 10.11.1 did not allow me to edit Availability.h. How did you do it (if you did)?

Also, I could not even build gcc48, again apparently due to the same issue with Availability.h.

[redwoodtree@…]

If you are inclined to attempt the modification to the file you have to temporarily turn off restricted file system access through rebooting into the Recovery Partition. Instructions elsewhere on the 'net .

[ryandesign (Ryan Carsten Schmidt)]

Replying to murrayeisenberg@…:

Replying to jeremyhu@…:

Yes. If you want, you can just manually edit Availability.h to replace the 'defined(__has_feature)' with 'defined(__has_attribute)' for the OSX and iOS availability macros, but you do so at your own risk because you know what you're doing ;)

Even using sudo with an admin account on OS X 10.11.1 did not allow me to edit Availability.h. How did you do it (if you did)?

System Integrity Protection (SIP), a new feature as of OS X 10.11 El Capitan, will not allow you to edit files in system locations like /usr. SIP can be turned off, but I recommend you don't do that.

Also, I could not even build gcc48, again apparently due to the same issue with Availability.h.

Yes.

[murrayeisenberg@…]

Replying to ryandesign@…:

Replying to murrayeisenberg@…:

Replying to jeremyhu@…:

Yes. If you want, you can just manually edit Availability.h to replace the 'defined(__has_feature)' with 'defined(__has_attribute)' for the OSX and iOS availability macros, but you do so at your own risk because you know what you're doing ;)

Even using sudo with an admin account on OS X 10.11.1 did not allow me to edit Availability.h. How did you do it (if you did)?

System Integrity Protection (SIP), a new feature as of OS X 10.11 El Capitan, will not allow you to edit files in system locations like /usr. SIP can be turned off, but I recommend you don't do that.

Also, I could not even build gcc48, again apparently due to the same issue with Availability.h.

Yes.

Yes, I know about SIP and how to turn it on and off, but for the obvious reasons hesitate to do so. So:

1. Is there to be some other workaround?
2. In case I dare to turn off SIP temporarily...

Is it literally just the several instances of 'defined(__has_feature)' that have to be replaced? I ask because in Availability.h there are other mentions of "availability", such as in '#if __has_feature(attribute_availability_*)' where what follows 'availability' could be 'twos', 'watchOS', 'app_extension', etc.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to murrayeisenberg@…:

Replying to ryandesign@…:

Replying to murrayeisenberg@…:

Replying to jeremyhu@…:

Yes. If you want, you can just manually edit Availability.h to replace the 'defined(__has_feature)' with 'defined(__has_attribute)' for the OSX and iOS availability macros, but you do so at your own risk because you know what you're doing ;)

Even using sudo with an admin account on OS X 10.11.1 did not allow me to edit Availability.h. How did you do it (if you did)?

System Integrity Protection (SIP), a new feature as of OS X 10.11 El Capitan, will not allow you to edit files in system locations like /usr. SIP can be turned off, but I recommend you don't do that.

Also, I could not even build gcc48, again apparently due to the same issue with Availability.h.

Yes.

Yes, I know about SIP and how to turn it on and off, but for the obvious reasons hesitate to do so. So:

1. Is there to be some other workaround?
2. In case I dare to turn off SIP temporarily...

Is it literally just the several instances of 'defined(__has_feature)' that have to be replaced?

Only the ones that are preceding __has_attribute() usage. Don't replace the ones that are correctly guarding __has_feature() usage. If you don't know what that means, then don't make any changes.

I ask because in Availability.h there are other mentions of "availability", such as in '#if __has_feature(attribute_availability_*)' where what follows 'availability' could be 'twos', 'watchOS', 'app_extension', etc.

I suggest you don't make manual changes if you're not absolutely clear to you what the problem is just by looking at the code block shown in comment:24. Making a mistake in editing that file can have further fallout.

[jeremyhu (Jeremy Huddleston Sequoia)]

Can you just use gcc5 instead?

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #49463.

[murrayeisenberg@…]

Replying to jeremyhu@…:

Can you just use gcc5 instead?

No, at least not on some of the ports that failed to install: they demanded the +gcc48 variant. (Sorry, right now I don't remember which ones.)

[ryandesign (Ryan Carsten Schmidt)]

Some ports might have gcc48 as the default variant (probably because gcc48 was the latest stable version at the time). Some ports might not even have newer gcc variants. If so, those ports should be updated to have newer gcc variants, and gcc5 should be set as the default, because gcc5 is now the latest stable version.

Then there's OpenBLAS, which uses dragonegg, for which dragonegg-3.4-gcc-4.8 is the latest version. However, dragonegg only gets used if you use clang. OpenBLAS does have a gcc49 variant that could be used. However, that might be bad on OS X 10.9 or later if OpenBLAS has C++ code (I don't know if it does).

[yannis1962@…]

Cc Me!

[yannis1962@…]

Cc Me!

[yannis1962@…]

Cc Me!

[murrayeisenberg@…]

Replying to jeremyhu@…:

Replying to murrayeisenberg@…:

Replying to ryandesign@…:

Replying to murrayeisenberg@…:

Replying to jeremyhu@…:

Yes. If you want, you can just manually edit Availability.h to replace the 'defined(__has_feature)' with 'defined(__has_attribute)' for the OSX and iOS availability macros, but you do so at your own risk because you know what you're doing ;)

Even using sudo with an admin account on OS X 10.11.1 did not allow me to edit Availability.h. How did you do it (if you did)?

System Integrity Protection (SIP), a new feature as of OS X 10.11 El Capitan, will not allow you to edit files in system locations like /usr. SIP can be turned off, but I recommend you don't do that.

Also, I could not even build gcc48, again apparently due to the same issue with Availability.h.

Yes.

Yes, I know about SIP and how to turn it on and off, but for the obvious reasons hesitate to do so. So:

1. Is there to be some other workaround?
2. In case I dare to turn off SIP temporarily...

Is it literally just the several instances of 'defined(__has_feature)' that have to be replaced?

Only the ones that are preceding __has_attribute() usage. Don't replace the ones that are correctly guarding __has_feature() usage. If you don't know what that means, then don't make any changes.

I ask because in Availability.h there are other mentions of "availability", such as in '#if __has_feature(attribute_availability_*)' where what follows 'availability' could be 'twos', 'watchOS', 'app_extension', etc.

I suggest you don't make manual changes if you're not absolutely clear to you what the problem is just by looking at the code block shown in comment:24. Making a mistake in editing that file can have further fallout.

OK, just making the change of that one line of that one block of code in Availability.h, in a copy of Availability.h in /opt/local/include, seems to fix things for the nonce.

[mojca (Mojca Miklavec)]

Cc Me!

[alex@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #49589.

[jianguohsiang82@…]

Cc Me!

[akimd (Akim Demaille)]

Cc Me!

[bungernut@…]

Cc Me!

[bungernut@…]

Cc Me!

[bungernut@…]

Cc Me!

[majoc-at-astro (majoc-at-astro)]

Cc Me!

[dhoese@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #49726.

[michelle.lynn.gill@…]

Cc Me!

[elenaheikkila@…]

Cc Me!

[tonordon@…]

Cc Me!

[yaseppochi (Stephen J. Turnbull)]

Replying to murrayeisenberg@…:

OK, just making the change of that one line of that one block of code in Availability.h, in a copy of Availability.h in /opt/local/include, seems to fix things for the nonce.

This worked for me, too, in building gcc48. I expect it will get me an R build without messing with variants, too. Thanks for the hint!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #49887.

[shiqiu@…]

Cc Me!

[psiqueira (Paul Siqueira)]

I just tried copy and pasting Availability.h as suggested by michaelbyrne1978@…, and this doesn't seem to work. Iit wants me to turn of SIP which I would rather not do.

[MichaelB7 (Michael Byrne)]

patched Availability.h - just copy and paste into usr/include/ - you need to turn off SIP, sudo privileges required

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #50025.

[murrayeisenberg@…]

Replying to siqueira@…:

I just tried copy and pasting Availability.h as suggested by michaelbyrne1978@…, and this doesn't seem to work. Iit wants me to turn of SIP which I would rather not do.

Did you try the workaround of copying Availability.h into /opt/local/include and doing the edits in the copy.? As I noted in another reply, that worked for me.

[bgantner@…]

Replying to murrayeisenberg@…:

Replying to siqueira@…:

I just tried copy and pasting Availability.h as suggested by michaelbyrne1978@…, and this doesn't seem to work. Iit wants me to turn of SIP which I would rather not do.

Did you try the workaround of copying Availability.h into /opt/local/include and doing the edits in the copy.? As I noted in another reply, that worked for me.

This worked for me, but with one addition. I had to change both the OSX and iOS lines. Copied the Availability.h from /usr/include to /opt/local/include and changed two lines. After that, gcc48 compiled fine.

/* for use marking APIs available info for Mac OSX */
#if defined(__has_attribute)                                                   <------CHANGE HERE (1 of 2)
  #if __has_attribute(availability)
    #define __OSX_UNAVAILABLE                    __OS_AVAILABILITY(macosx,unavailable)
 
/* for use marking APIs available info for iOS */
#if defined(__has_attribute)                                                  <------CHANGE HERE (2 of 2)
  #if __has_attribute(availability)
    #define __IOS_UNAVAILABLE                    __OS_AVAILABILITY(ios,unavailable)

Thanks for the fix!

[dershow]

Cc Me!

[Serge3leo (Serguei E. Leontiev)]

Cc Me!

[Serge3leo (Serguei E. Leontiev)]

Thanks for dar1985.lukic@…. Patch "define_nonstandard_clang_macros.patch"​ work for me (port build gcc48 - Ok).

Workaround for me:

• copy define_nonstandard_clang_macros.patch to /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/lang/gcc48/files/ ;
• sudo port edit gcc48 and add line patchfiles-append define_non_standard_clang_macros.patch.

[Serge3leo (Serguei E. Leontiev)]

Patch for dports/lang/gcc48 base at define_non_standard_clang_macros.patch

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #50191.

[jhi]

Cc Me!

[jhi]

FWIW, I tried:

sudo port uninstall --follow-dependents gcc48

which did finish successfully, but that did not seem to remove various stuff that had "+gcc48" variants, so "gcc48" kept being updated, and failing. I uninstalled the "+gcc48" variant-requiring ports manually (with the similar uninstall invocation), and then the system gave up trying to reinstall "gcc48".

[Polyergic (Shad Sterling)]

Cc Me!

[t-remke@…]

Cc Me!

[macports@…]

Appears to work for me too. Thanks. Although the proper directory for the patch file appears to be

/opt/local/var/macports/sources/rsync.macports.org/release/ports/lang/gcc48/files

Replying to leo@…:

Thanks for dar1985.lukic@…. Patch "define_nonstandard_clang_macros.patch"​ work for me (port build gcc48 - Ok).

Workaround for me:

• copy define_nonstandard_clang_macros.patch to /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/lang/gcc48/files/ ;
• sudo port edit gcc48 and add line patchfiles-append define_non_standard_clang_macros.patch.

[jeremyhu (Jeremy Huddleston Sequoia)]

Oh yeah, I should've closed this.

Fixed in Xcode 7.3.

[texas-swift (Spencer Swift)]

Cc Me!

[texas-swift (Spencer Swift)]

Replying to jeremyhu@…:

Fixed in Xcode 7.3.

Is Xcode 7.3 about to release? Apple just released v7.2.1 the other day.

[jeremyhu (Jeremy Huddleston Sequoia)]

Sorry, I should have said that it's fixed in Xcode 7.3 beta 1 and later. 7.3 beta2 was released about a week and a half ago. See ​https://developer.apple.com/news

No, the fix is not in 7.2.1.

[mvenkadesan (MV)]

Cc Me!

[mvenkadesan (MV)]

Cc Me!

[mv@…]

Cc Me!

[billygr (billy)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #50554.

Let's leave this issue open until Xcode 7.3 is released, so people can find it.

[texas-swift (Spencer Swift)]

Replying to jeremyhu@…:

Sorry, I should have said that it's fixed in Xcode 7.3 beta 1 and later. 7.3 beta2 was released about a week and a half ago. See ​https://developer.apple.com/news

jeremyhu,

Are you sure the fix is provided by Xcode? I downloaded and installed Xcode 7.3 beta 2. It installs simply via drag-n-drop to wherever, /Applications in my case. So the installation does not touch /usr/include that I see.

I have selected Xcode 7.3 beta 2 as my default:

cf-vpn-hw-swift-1(6)$ xcode-select -p
/Applications/Xcode-beta.app/Contents/Developer

and attempted to install/update the command line tools:

cf-vpn-hw-swift-1(7)$ sudo xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates

But /usr/include/Availability.h is the same, and gcc48 still fails to build.

Any thoughts or other suggestions?

Thanks,
Spencer

[jeremyhu (Jeremy Huddleston Sequoia)]

Look at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/Availability.h ... the fix should be there in Xcode 7.3 beta.

[texas-swift (Spencer Swift)]

Okay, I do see an updated Availability.h under the Xcode-beta.app/, but for some reason Macports seems to still be looking at the header file at

/usr/include/Availability.h

rather than the updated one in the Xcode-beta SDK:

/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/Availability.h

Admittedly, I am a Linux developer and not a Mac developer, so I am not very adept with Xcode. Do you have any suggestions for making Macports pick up Xcode-beta SDK?

Thanks again, Spencer

[dhoese@…]

Cc Me!

[steve-macports@…]

Cc Me!

[anddam (Andrea D'Amore)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

Installing the beta command line tools (I think it is at ​http://adcdownload.apple.com/Developer_Tools/Command_Line_Tools_OS_X_10.11_for_Xcode_7.3_beta_5/Command_Line_Tools_OS_X_10.11_for_Xcode_7.3_beta_5.dmg) should get you the updated /usr/include/Availability.h

[texas-swift (Spencer Swift)]

Replying to jeremyhu@…:

THANK YOU jeremyhu!

Indeed that worked for me. Installing the Beta Command Line Tools from disk image put the files at the root level. As I mentioned in the my other posts, I started by installing Xcode Beta and installing the Beta Command Line Tools from within Xcode Beta. That put the tools under Xcode rather than the disk root level. And OS X SIP prevented me from just moving/copying the header file.

By the way, your link would not work for my basic Apple Developer account. But I just logged in, went to Downloads and found the disk image myself.

[russellhanson@…]

Wow. Thanks @jeremyhu and @vfrspencer...

This Availability.h bug is one of the worst... All because of Mac System Integrity Protection (SIP), can't just fix the header file and move on with it.

I was forced to install gcc5, and got sucked down this rabbit hole. Among other reasons to end up here.

Installing Xcode_7.3_beta_5.dmg doesn't fix it.

Installing Command_Line_Tools_OS_X_10.11_for_Xcode_7.3_beta_5.dmg does.

It's still funny that the Command Line Tools dmg BETA can get around rootless SIP (​http://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/). Doesn't that mean that anything pretending to be a Command Line Tools installer (or whatever) can evade rootlessness also???

[jeremyhu (Jeremy Huddleston Sequoia)]

Doesn't that mean that anything pretending to be a Command Line Tools installer (or whatever) can evade rootlessness also???

No. The package needs to be signed appropriately to install into system locations.

[russellhanson@…]

In case anyone was curious what the diff looks like here:

$ diff ~/usr-include-Availability-bak.h /usr/include/Availability.h 
133a134,135
> #define __MAC_10_11_3       101103
> #define __MAC_10_11_4       101104
159a162
> #define __IPHONE_9_3     90300
163a167
> #define __TVOS_9_2       90200
224c228
< #if defined(__has_feature)
---
> #if defined(__has_attribute)
246c250
< #if defined(__has_feature)
---
> #if defined(__has_attribute) 

[mf2k (Frank Schima)]

Has duplicate #50656.

[mf2k (Frank Schima)]

Is this ticket still relevant? It builds on the El Capitan buildbot.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mf2k:

Is this ticket still relevant? It builds on the El Capitan buildbot.

Jeremy said the fix is in the Xcode 7.3 version of the command line tools. That's what we use on the El Capitan buildbot.

We could add the xcodeversions portgroup to the gcc48 port (and any other affected gcc ports?) and use it to require Xcode 7.3 or later on El Capitan. It wouldn't help users who have Xcode 7.3 but not the Xcode 7.3 version of the command line tools (we never developed a way to test the version of the command line tools), but it might be better than nothing.