Opened 9 years ago
Last modified 7 years ago
#48471 assigned defect
FSF gcc48 fails to compile projects on El Capitan due to OS X SDK bug in Availability.h
Reported by: | jasonw@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.3 |
Keywords: | elcapitan haspatch | Cc: | ryandesign (Ryan Carsten Schmidt), iqgrande, vaccari@…, epaell, alan.mock@…, fracai, glen@…, joaogeada (Joao Geada), matteo.tommasini@…, kurtjaeke@…, xuod (Cyrille Doux), skymoo (Adam Mercer), redwoodtree@…, hapaguy (Brian Kurt Fujikawa), maehne (Torsten Maehne), grant.jenks@…, jeremyhu (Jeremy Huddleston Sequoia), zhangdai1992@…, arunava.mukherjee@…, murrayeisenberg@…, mojca (Mojca Miklavec), alex@…, jianguohsiang82@…, akimd (Akim Demaille), bungernut@…, majoc-at-astro (majoc-at-astro), tonordon@…, caciolli@…, shiqiu@…, volker@…, dershow, Serge3leo (Serguei E. Leontiev), alansuphd@…, jhi, Polyergic (Shad Sterling), t-remke@…, texas-swift (Spencer Swift), sonnyrhim@…, steve-macports@…, anddam (Andrea D'Amore), lucas.pettey@… |
Port: | gcc48 |
Description
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.
Attachments (4)
Change History (119)
Changed 9 years ago by jasonw@…
comment:1 Changed 9 years ago by Ionic (Mihai Moldovan)
Keywords: | elcapitan added |
---|---|
Owner: | changed from macports-tickets@… to mww@… |
comment:2 Changed 9 years ago by 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)
comment:3 Changed 9 years ago by macports@…
I'm getting the same error on OS X 10.11 Beta (15A243d), Xcode 7.0 beta 5 (7A176x)
comment:4 Changed 9 years ago by jasonw@…
Same results with public beta 5:
OS: 10.11 Beta (15A262e) [El Capitan, Public Beta 5]
Xcode: Version 7.0 beta 6 (7A192o)
comment:5 Changed 9 years ago by jasonw@…
Same results with GM seed:
OS: 10.11 (15A282a) [El Capitan, GM seed]
Xcode: Version 7.0 (7A218)
comment:6 Changed 9 years ago by 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
comment:7 follow-up: 10 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added |
---|
As a workaround, try installing gcc49, gcc5 or gcc6?
comment:10 follow-up: 11 Changed 9 years ago by 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 :(
comment:11 follow-up: 12 Changed 9 years ago by 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
comment:12 Changed 9 years ago by 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!
comment:13 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | yannis1962@… added |
---|
Has duplicate #49068.
comment:15 Changed 9 years ago by 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.
Changed 9 years ago by MoogHub
Attachment: | define_non_standard_clang_macros.patch added |
---|
Patch that adds additional fixes to fixincludes.
comment:24 follow-up: 26 Changed 9 years ago by 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.
comment:26 follow-up: 27 Changed 9 years ago by 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.
comment:27 Changed 9 years ago by 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 :-/
comment:29 Changed 9 years ago by xuod (Cyrille Doux)
Cc: | doux.cyrille@… added |
---|
Cc Me!
The patch works for me ! Thanks a lot !
comment:35 Changed 9 years ago by 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 =/
comment:38 Changed 9 years ago by arthur.michaut@…
same bug for me while I was trying to install py27-scipy
comment:39 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Summary: | gcc48 @4.8.5 build failure on OS X 10.11 [El Capitan, Public Beta 3] → FSF gcc48 fails to compile projects on El Capitan due to OS X SDK bug in Availability.h |
---|
comment:40 Changed 9 years ago by 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
comment:41 follow-up: 48 Changed 9 years ago by 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 ;)
comment:48 follow-up: 50 Changed 9 years ago by 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.
comment:49 Changed 9 years ago by 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 .
comment:50 follow-up: 51 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | murrayeisenberg@… added |
---|
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.
comment:51 follow-up: 52 Changed 9 years ago by 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:
- Is there to be some other workaround?
- 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.
comment:52 follow-up: 60 Changed 9 years ago by 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:
- Is there to be some other workaround?
- 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.
comment:53 follow-up: 55 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Can you just use gcc5 instead?
comment:55 Changed 9 years ago by 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.)
comment:56 Changed 9 years ago by 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).
comment:60 follow-up: 75 Changed 9 years ago by 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:
- Is there to be some other workaround?
- 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.
comment:73 Changed 9 years ago by elenaheikkila@…
Cc: | elenaheikkila@… added |
---|
comment:75 Changed 9 years ago by 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!
comment:76 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | caciolli@… added |
---|
Has duplicate #49887.
comment:78 follow-up: 80 Changed 9 years ago by 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.
Changed 9 years ago by MichaelB7 (Michael Byrne)
Attachment: | Availability.h added |
---|
patched Availability.h - just copy and paste into usr/include/ - you need to turn off SIP, sudo privileges required
comment:79 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | volker@… added |
---|
Has duplicate #50025.
comment:80 follow-up: 81 Changed 9 years ago by 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.
comment:81 Changed 9 years ago by 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!
comment:84 follow-up: 91 Changed 9 years ago by 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 linepatchfiles-append define_non_standard_clang_macros.patch
.
Changed 9 years ago by Serge3leo (Serguei E. Leontiev)
Attachment: | gcc48-48471-151225.patch added |
---|
Patch for dports/lang/gcc48 base at define_non_standard_clang_macros.patch
comment:85 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | alansuphd@… added |
---|---|
Keywords: | haspatch added |
Has duplicate #50191.
comment:86 Changed 9 years ago by elenaheikkila@…
Cc: | elenaheikkila@… removed |
---|
comment:88 Changed 9 years ago by 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".
comment:91 Changed 9 years ago by 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 linepatchfiles-append define_non_standard_clang_macros.patch
.
comment:92 follow-up: 94 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Oh yeah, I should've closed this.
Fixed in Xcode 7.3.
comment:94 Changed 9 years ago by 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.
comment:95 follow-up: 101 Changed 9 years ago by 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.
comment:100 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | sonnyrhim@… added |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
Has duplicate #50554.
Let's leave this issue open until Xcode 7.3 is released, so people can find it.
comment:101 Changed 9 years ago by 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
comment:102 Changed 9 years ago by 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.
comment:103 Changed 9 years ago by 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
comment:107 follow-up: 108 Changed 9 years ago by 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
comment:108 Changed 9 years ago by 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.
comment:109 Changed 9 years ago by 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???
comment:110 Changed 9 years ago by 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.
comment:111 Changed 9 years ago by 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)
comment:112 Changed 8 years ago by kurthindenburg (Kurt Hindenburg)
Owner: | changed from mww@… to macports-tickets@… |
---|---|
Status: | reopened → assigned |
comment:113 Changed 7 years ago by mf2k (Frank Schima)
Cc: | lucas.pettey@… added |
---|
Has duplicate #50656.
comment:114 follow-up: 115 Changed 7 years ago by mf2k (Frank Schima)
Is this ticket still relevant? It builds on the El Capitan buildbot.
comment:115 Changed 7 years ago by 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.
Please remember to CC the maintainer(s) next time, if any.