Created attachment 32886 [details] make log Will not build on latest OS X and Xcode... Attaching log...
Looks like the Mac OS X's headers are not C99/C++98 compatible at all: /Applications/Xcode6-Beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/Availability.h:174:44: error: missing binary operator before token "(" #if defined(__has_feature) && __has_feature(attribute_availability_with_message) ^
(In reply to Andrew Pinski from comment #1) > Looks like the Mac OS X's headers are not C99/C++98 compatible at all: > > /Applications/Xcode6-Beta.app/Contents/Developer/Platforms/MacOSX.platform/ > Developer/SDKs/MacOSX10.10.sdk/usr/include/Availability.h:174:44: error: > missing binary operator before token "(" > #if defined(__has_feature) && > __has_feature(attribute_availability_with_message) > ^ This error is correct because with the preprocessor && does not short cutting if the first operand is true. So look like we need a fixincludes of this issue. You should also report this bug to Apple too since their headers don't support C99/C++98 preprocessors correctly.
Alright, reported to apple as well [:
(In reply to Andrew Pinski from comment #2) > (In reply to Andrew Pinski from comment #1) > > Looks like the Mac OS X's headers are not C99/C++98 compatible at all: > > > > /Applications/Xcode6-Beta.app/Contents/Developer/Platforms/MacOSX.platform/ > > Developer/SDKs/MacOSX10.10.sdk/usr/include/Availability.h:174:44: error: > > missing binary operator before token "(" > > #if defined(__has_feature) && > > __has_feature(attribute_availability_with_message) > > ^ > > This error is correct because with the preprocessor && does not short > cutting if the first operand is true. If this is true, it sucks. Short-cutting simplifies writing such conditions. But then the CPP manual is wrong: https://gcc.gnu.org/onlinedocs/gcc-4.9.0/cpp/If.html#If "Arithmetic operators for addition, subtraction, multiplication, division, bitwise operations, shifts, comparisons, and logical operations (&& and ||). The latter two obey the usual short-circuiting rules of standard C. "
This has nothing to do with evaluation, it's a syntax error.
*** Bug 61432 has been marked as a duplicate of this bug. ***
So it turns out there is a defect report against the C, see PR 36453 but that is only for #elif and not #if defined(a) && a()
Created attachment 32949 [details] Patch to compile gcc on OS X 10.10 Yosemite Fixed everything I encountered during build. GCC compiled successfully in three-stage build and is working fine for me.
(In reply to Ilya Mikhaltsou from comment #8) > Created attachment 32949 [details] > Patch to compile gcc on OS X 10.10 Yosemite > > Fixed everything I encountered during build. GCC compiled successfully in > three-stage build and is working fine for me. Hi Ilya, If you want to see this working for future versions of GCC, perhaps it would be better to get your patch into the official GCC. Check https://gcc.gnu.org/contribute.html
(In reply to Manuel López-Ibáñez from comment #9) > (In reply to Ilya Mikhaltsou from comment #8) > > Created attachment 32949 [details] > > Patch to compile gcc on OS X 10.10 Yosemite > > > > Fixed everything I encountered during build. GCC compiled successfully in > > three-stage build and is working fine for me. > > Hi Ilya, > > If you want to see this working for future versions of GCC, perhaps it would > be better to get your patch into the official GCC. Check > https://gcc.gnu.org/contribute.html Thanks. I think, it may be better first to ensure this works for everybody affected. Anyway, I hope someone else picks it up from there.
(In reply to kassafari from comment #3) > Alright, reported to apple as well [: Do you have a radar number or OpenRadar link for easier tracking?
I'm sure I sound like an idiot asking this, but I tried copying and pasting the raw unified data of the patch and pasting it into a .diff file, then running patch < ~/Documents/patch.diff. Nothing happened. How do I implement this fix?
This remains an issue on the latest release of 4.9.1 - xgcc: warning: couldn’t understand kern.osversion ‘14.0.0 In file included from /usr/include/stdio.h:65:0, from ../../.././libgcc/../gcc/tsystem.h:87, from ../../.././libgcc/libgcc2.c:27: /usr/include/Availability.h:174:44: error: missing binary operator before token "(" #if defined(__has_feature) && __has_feature(attribute_availability_with_message) ^ In file included from /usr/include/stdio.h:65:0, from ../../.././libgcc/../gcc/tsystem.h:87, from ../../.././libgcc/libgcc2.c:27: /usr/include/Availability.h:184:44: error: missing binary operator before token "(" #if defined(__has_feature) && __has_feature(attribute_availability_app_extension) ^ make[5]: *** [_muldi3.o] Error 1 make[4]: *** [multi-do] Error 1 make[3]: *** [all-multi] Error 2 make[2]: *** [all-stage1-target-libgcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 The patch provided on 4.8.3 also doesn't apply to 4.9.1, which was pretty much expected. Is there status/timeline for folding in 10.10 support?
The issue with Availability.h has been fixed as of Developer Preview 4, however `all-stage1-target-libsanitizer` still fails with Error 2.
(In reply to James Clarke from comment #14) > The issue with Availability.h has been fixed as of Developer Preview 4, > however `all-stage1-target-libsanitizer` still fails with Error 2. I should note that I am building 4.8.3 with Homebrew.
Created attachment 33180 [details] Patch For GCC 4.9.1 On Yosemite Requires DP 4 (or above), as I have also removed the fix for Availability.h which was only needed in DP 3 and below.
(In reply to James Clarke from comment #16) > Created attachment 33180 [details] > Patch For GCC 4.9.1 On Yosemite > > Requires DP 4 (or above), as I have also removed the fix for Availability.h > which was only needed in DP 3 and below. Worked great for me on DP4, thanks!
Guys, a question... how can i apply the patch? I've read that i have to add: patch do url "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180" sha1 "def0cb036a255175db86f106e2bb9dd66d19b702" end But i don't know WHERE to add that in the formula when i use brew edit gcc... Any help? Thanks!
(In reply to aggrostyle from comment #18) > Guys, a question... how can i apply the patch? I've read that i have to add: > > patch do > url "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180" > sha1 "def0cb036a255175db86f106e2bb9dd66d19b702" > end > > But i don't know WHERE to add that in the formula when i use brew edit gcc... > > Any help? Thanks! Running this command while in the gcc source directory patch -p1 < patchfile where patchfile is the name you saved Clarke's attachment with is a quick way to apply it; I'm not sure about homebrew specifics as I was building from source manually.
(In reply to aggrostyle from comment #18) > Guys, a question... how can i apply the patch? I've read that i have to add: > > patch do > url "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180" > sha1 "def0cb036a255175db86f106e2bb9dd66d19b702" > end > > But i don't know WHERE to add that in the formula when i use brew edit gcc... > > Any help? Thanks! I included the patch directly in the contents of the formula (see https://github.com/jrtc27/homebrew/commit/a94f371cb24fb68e2f55e701eb2a25a56253b726), but it should also work if you add the patch do ... end block just before the fails_with :gcc_4_0 line (though I haven't tried that).
Thank you! It worked perfect last night!
Was your gcc.rb git post intended as a replacement file for gcc.rb, or as a patch for it? Either way, using it for either purpose has been unsuccessful for me. I am getting: /usr/bin/patch: **** malformed patch at line 13: version_as_macro (void)
(In reply to Eric Martin from comment #22) > Was your gcc.rb git post intended as a replacement file for gcc.rb, or as a > patch for it? Either way, using it for either purpose has been unsuccessful > for me. I am getting: > /usr/bin/patch: **** malformed patch at line 13: version_as_macro (void) However, your patch do ... end block before the line you suggested allowed it to compile when setting autolibs=4 and compiling --with-gcc=clang
(In reply to James Clarke from comment #16) > Created attachment 33180 [details] > Patch For GCC 4.9.1 On Yosemite > > Requires DP 4 (or above), as I have also removed the fix for Availability.h > which was only needed in DP 3 and below. It looks like gcc are gonna require someone to submit this patch to their mailing list before we see any further activity on this. Could you possibly do that? Would massively appreciate it. More details are here: https://gcc.gnu.org/contribute.html
(In reply to Dominyk Tiller from comment #24) > It looks like gcc are gonna require someone to submit this patch to their > mailing list before we see any further activity on this. Could you possibly > do that? Would massively appreciate it. More details are here: > https://gcc.gnu.org/contribute.html Working on it now. Need to clean it up, separate the diffs, add relevant test cases and check it all still compiles and passes the tests before submitting though. And of course doing a full bootstrap (a required test) takes quite a while. Will post an update when I've submitted the patches.
Patches have been sent to the mailing list - https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02344.html and https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02345.html.
Updated patches: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02415.html
I noticed that MacPorts is using… #if SANITIZER_MAC && ( !defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T) and # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T rather than just… #if SANITIZER_MAC && __DARWIN_64_BIT_INO_T and # if __DARWIN_64_BIT_INO_T in their patch for gcc49… https://trac.macports.org/browser/trunk/dports/lang/gcc49/files/patch-10.10.diff Should we be doing the same?
(In reply to Jack Howarth from comment #28) > I noticed that MacPorts is using… > > #if SANITIZER_MAC && ( !defined(__DARWIN_64_BIT_INO_T) || > __DARWIN_64_BIT_INO_T) > > and > > # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T > > rather than just… > > > #if SANITIZER_MAC && __DARWIN_64_BIT_INO_T > > and > > # if __DARWIN_64_BIT_INO_T > > in their patch for gcc49… > > https://trac.macports.org/browser/trunk/dports/lang/gcc49/files/patch-10.10. > diff > > Should we be doing the same? That's because they're using my original patch from this bug report (https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180), which itself is based off Ilya Mikhaltsou's patch (https://gcc.gnu.org/bugzilla/attachment.cgi?id=32949, also from this bug report). I don't know why Ilya decided to default to a 64-bit dirent struct, as the documentation clearly states that it is only 64-bit when the _DARWIN_FEATURE_64_BIT_INODE macro is defined (https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/dir.5.html#//apple_ref/doc/man/5/dir). This is different from __DARWIN_64_BIT_INO_T, but you can see in sys/cdefs.h that _DARWIN_FEATURE_64_BIT_INODE is only defined (to 1) when __DARWIN_64_BIT_INO_T is true. Please note that I have updated my patch to use the public _DARWIN_FEATURE_64_BIT_INODE macro, and to check whether it is defined rather than its value (seeing as the documentation only refers to its definition, not its value). The updated patches are at https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02427.html.
The proposed changes in v4 of the patch aren't building here on 10.9. I don't see how # if defined(_DARWIN_FEATURE_64_BIT_INODE) can completely substitute for… # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T as sys/cdefs.h shows… /* * _DARWIN_FEATURE_64_BIT_INODE indicates that the ino_t type is 64-bit, and * structures modified for 64-bit inodes (like struct stat) will be used. */ #if __DARWIN_64_BIT_INO_T #define _DARWIN_FEATURE_64_BIT_INODE 1 #endif which means that… # if defined(_DARWIN_FEATURE_64_BIT_INODE) is effectively only # if __DARWIN_64_BIT_INO_T as the definition of _DARWIN_FEATURE_64_BIT_INODE only checks if __DARWIN_64_BIT_INO_T is set and not if it is undefined as well.
(In reply to James Clarke from comment #29) > (In reply to Jack Howarth from comment #28) > > I noticed that MacPorts is using… > > > > #if SANITIZER_MAC && ( !defined(__DARWIN_64_BIT_INO_T) || > > __DARWIN_64_BIT_INO_T) > > > > and > > > > # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T > > > > rather than just… > > > > > > #if SANITIZER_MAC && __DARWIN_64_BIT_INO_T > > > > and > > > > # if __DARWIN_64_BIT_INO_T > > > > in their patch for gcc49… > > > > https://trac.macports.org/browser/trunk/dports/lang/gcc49/files/patch-10.10. > > diff > > > > Should we be doing the same? > > That's because they're using my original patch from this bug report > (https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180), which itself is > based off Ilya Mikhaltsou's patch > (https://gcc.gnu.org/bugzilla/attachment.cgi?id=32949, also from this bug > report). I don't know why Ilya decided to default to a 64-bit dirent struct, > as the documentation clearly states that it is only 64-bit when the > _DARWIN_FEATURE_64_BIT_INODE macro is defined > (https://developer.apple.com/library/mac/documentation/Darwin/Reference/ > ManPages/man5/dir.5.html#//apple_ref/doc/man/5/dir). This is different from > __DARWIN_64_BIT_INO_T, but you can see in sys/cdefs.h that > _DARWIN_FEATURE_64_BIT_INODE is only defined (to 1) when > __DARWIN_64_BIT_INO_T is true. > > Please note that I have updated my patch to use the public > _DARWIN_FEATURE_64_BIT_INODE macro, and to check whether it is defined > rather than its value (seeing as the documentation only refers to its > definition, not its value). The updated patches are at > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02427.html. I wasn't doing much thinking on the topic, I've simply made the minimal necessary changes to a) compile on 10.10 and b) to work exactly the same as before on previous versions. If you think it is redundant, there are no objective reasons for keeping it that way.
(In reply to Ilya Mikhaltsou from comment #31) > (In reply to James Clarke from comment #29) > > (In reply to Jack Howarth from comment #28) > > > I noticed that MacPorts is using… > > > > > > #if SANITIZER_MAC && ( !defined(__DARWIN_64_BIT_INO_T) || > > > __DARWIN_64_BIT_INO_T) > > > > > > and > > > > > > # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T > > > > > > rather than just… > > > > > > > > > #if SANITIZER_MAC && __DARWIN_64_BIT_INO_T > > > > > > and > > > > > > # if __DARWIN_64_BIT_INO_T > > > > > > in their patch for gcc49… > > > > > > https://trac.macports.org/browser/trunk/dports/lang/gcc49/files/patch-10.10. > > > diff > > > > > > Should we be doing the same? > > > > That's because they're using my original patch from this bug report > > (https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180), which itself is > > based off Ilya Mikhaltsou's patch > > (https://gcc.gnu.org/bugzilla/attachment.cgi?id=32949, also from this bug > > report). I don't know why Ilya decided to default to a 64-bit dirent struct, > > as the documentation clearly states that it is only 64-bit when the > > _DARWIN_FEATURE_64_BIT_INODE macro is defined > > (https://developer.apple.com/library/mac/documentation/Darwin/Reference/ > > ManPages/man5/dir.5.html#//apple_ref/doc/man/5/dir). This is different from > > __DARWIN_64_BIT_INO_T, but you can see in sys/cdefs.h that > > _DARWIN_FEATURE_64_BIT_INODE is only defined (to 1) when > > __DARWIN_64_BIT_INO_T is true. > > > > Please note that I have updated my patch to use the public > > _DARWIN_FEATURE_64_BIT_INODE macro, and to check whether it is defined > > rather than its value (seeing as the documentation only refers to its > > definition, not its value). The updated patches are at > > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02427.html. > > I wasn't doing much thinking on the topic, I've simply made the minimal > necessary changes to a) compile on 10.10 and b) to work exactly the same as > before on previous versions. If you think it is redundant, there are no > objective reasons for keeping it that way. I thought that was probably the case. I believe how it is now in my patch is correct, but I'm open to being challenged on it!
(In reply to Jack Howarth from comment #30) > The proposed changes in v4 of the patch aren't building here on 10.9. I > don't see how > > # if defined(_DARWIN_FEATURE_64_BIT_INODE) > > can completely substitute for… > > # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T > > as sys/cdefs.h shows… > > /* > * _DARWIN_FEATURE_64_BIT_INODE indicates that the ino_t type is 64-bit, and > * structures modified for 64-bit inodes (like struct stat) will be used. > */ > #if __DARWIN_64_BIT_INO_T > #define _DARWIN_FEATURE_64_BIT_INODE 1 > #endif > > which means that… > > # if defined(_DARWIN_FEATURE_64_BIT_INODE) > > is effectively only > > # if __DARWIN_64_BIT_INO_T > > as the definition of _DARWIN_FEATURE_64_BIT_INODE only checks if > __DARWIN_64_BIT_INO_T is set and not if it is undefined as well. I was able to perform a complete clean bootstrap on my system, so I'm curious as to what error(s) you got? I agree, the two are not equivalent, but the first one (!defined(X) || X) is wrong in my opinion, as if the macro is not defined, the documentation for dir(5) states that the 32-bit versions are used.
(In reply to James Clarke from comment #33) > I was able to perform a complete clean bootstrap on my system, so I'm > curious as to what error(s) you got? I’m also seeing a build failure on 10.9.4 13E28 with Xcode 5.1.1 5B1008, with your mailing list patches applied. I'll attach the log in a moment; it was generated by MacPorts during a 64-bit build of our libgcc port. > I agree, the two are not equivalent, but the first one (!defined(X) || X) is > wrong in my opinion, as if the macro is not defined, the documentation for > dir(5) states that the 32-bit versions are used. I got the build to succeed by changing # if defined(_DARWIN_FEATURE_64_BIT_INODE) to # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T in your second patch.
Created attachment 33461 [details] MacPorts log from a failed attempt to build libgcc @4.9.1_0 (x86_64) There’s a lot of text, I know. To see the environment and commands executed, search for "configure phase started" and "build phase started". As you might expect, the failure is near the end.
(In reply to Lawrence Velázquez from comment #34) > I got the build to succeed by changing > > # if defined(_DARWIN_FEATURE_64_BIT_INODE) > > to > > # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T > > in your second patch. Sorry, I might have gotten mixed up about precisely how I altered your patch. I'll do a couple of test builds and report back.
Okay, what I said initially was correct. This was the specific change I made. https://gist.github.com/larryv/9b1cd34a34733c10f734
Created attachment 33464 [details] Corrected dirent patch Couple of things: 1) The version of Sanitizer included with GCC 4.9.1 at least, and probably earlier, has the includes in the wrong order in sanitizer_platform_limits_posix.cc: #include "sanitizer_platform.h" #if SANITIZER_LINUX || SANITIZER_MAC #include "sanitizer_internal_defs.h" #include "sanitizer_platform_limits_posix.h" #include <arpa/inet.h> #include <dirent.h> Since sanitizer_platform_limits_posix.h is included before the system headers, _DARWIN_FEATURE_64_BIT_INODE is *not* defined for the second hunk of your patch, and the 32-bit dirent is always used. However, it *is* defined for the first hunk, so CHECK_SIZE_AND_OFFSET does try to access d_seekoff (and predictably fails). The ordering is fixed in Sanitizer upstream, but it's more robust to directly include sys/cdefs.h in sanitizer_platform_limits_posix.h to avoid relying on include ordering. 2) You should report this bug upstream. http://compiler-rt.llvm.org
(In reply to Lawrence Velázquez from comment #38) > 2) You should report this bug upstream. > > http://compiler-rt.llvm.org On second thought, they probably won't accept it because the patch is invalid. sanitizer_mac.cc explicitly defines _DARWIN_USE_64_BIT_INODE, which result in 64-bit dirents on all platforms that AddressSanitizer supports (Snow Leopard and newer). The correct fix is to disable the AddressSanitizer build entirely on platforms that don't support 64-bit inodes (Leopard and older).
Author: fxcoudert Date: Sun Sep 14 08:05:43 2014 New Revision: 215251 URL: https://gcc.gnu.org/viewcvs?rev=215251&root=gcc&view=rev Log: PR target/61407 * config/darwin-c.c (version_as_macro): Added extra 0 for OS X 10.10 and above. * config/darwin-driver.c (darwin_find_version_from_kernel): Removed kernel version check to avoid incrementing it after every major OS X release. (darwin_default_min_version): Avoid static memory buffer. * gcc.dg/darwin-minversion-1.c: Fixed formatting * gcc.dg/darwin-minversion-2.c: Fixed formatting * gcc.dg/darwin-minversion-3.c: Fixed formatting * gcc.dg/darwin-minversion-4.c: Added test for OS X 10.10 Added: trunk/gcc/testsuite/gcc.dg/darwin-minversion-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-c.c trunk/gcc/config/darwin-driver.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/darwin-minversion-1.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-2.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-3.c
Author: fxcoudert Date: Mon Sep 29 18:40:57 2014 New Revision: 215690 URL: https://gcc.gnu.org/viewcvs?rev=215690&root=gcc&view=rev Log: PR target/61407 * config/darwin-c.c (version_as_macro): Added extra 0 for OS X 10.10 and above. * config/darwin-driver.c (darwin_find_version_from_kernel): Removed kernel version check to avoid incrementing it after every major OS X release. (darwin_default_min_version): Avoid static memory buffer. * gcc.dg/darwin-minversion-1.c: Fixed formatting * gcc.dg/darwin-minversion-2.c: Fixed formatting * gcc.dg/darwin-minversion-3.c: Fixed formatting * gcc.dg/darwin-minversion-4.c: Added test for OS X 10.10 Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-4.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/darwin-c.c branches/gcc-4_9-branch/gcc/config/darwin-driver.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-2.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-3.c
The committed patch is incorrect. It makes an invalid assumption which breaks the usage of deployment targets such as 10.9.3. Please instead use the (GPL2) patch that I provided back in June and is available from MacPorts: https://trac.macports.org/browser/trunk/dports/lang/apple-gcc42/files/yosemite-deployment-target.patch I will also attach it, but it is based on gcc-4.2 (I do not intentionally read GPL3 code) and may require modification for usage in newer gcc.
Created attachment 33824 [details] gcc 4.2 based patch which handles tiny version numbers properly
*** Bug 63685 has been marked as a duplicate of this bug. ***
(In reply to Jeremy Huddleston Sequoia from comment #42) > The committed patch is incorrect. It makes an invalid assumption which > breaks the usage of deployment targets such as 10.9.3. All Apple doc I can find has deployment targets of the form 10.x or 10.x.0 (where x is integer, but not only one digit).
(In reply to Francois-Xavier Coudert from comment #45) > (In reply to Jeremy Huddleston Sequoia from comment #42) > > The committed patch is incorrect. It makes an invalid assumption which > > breaks the usage of deployment targets such as 10.9.3. > > All Apple doc I can find has deployment targets of the form 10.x or 10.x.0 > (where x is integer, but not only one digit). If Jeremy really disagreed on that change, he hasn't acted on it in the gcc49 MacPorts packaging that he maintains (which still uses the original proposed patch from https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02428.html). FYI, as far as llvm-gcc 4.2.1 is concerned, in my fink legacy package for Apple's llvm-gcc 4.2.1, I used a back port of our patch, http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/stable/main/finkinfo/languages/llvm-gcc42-yosemite.patch. Neither gcc 4.9.2 nor the patched llvm-gcc 4.2.1 has shown any problems on OS X 10.9.5.
Current status for Yosemite: - trunk has new failures on darwin, not specific to Yosemite ("end of stage 1" syndrome) - gcc 4.9.2, and the 4.9 branch, both build fine. - gcc 4.8.3 builds fine with a similar patch to those I committed to 4.9 and trunk Thus closing this one as fixed.
Created attachment 33932 [details] Patch for gcc 4.8 branch (based on gcc 4.8.3) This is the patch for GCC 4.8 branch (here based on 4.8.3) that allows to build it on Yosemite.
(In reply to Francois-Xavier Coudert from comment #45) > (In reply to Jeremy Huddleston Sequoia from comment #42) > > The committed patch is incorrect. It makes an invalid assumption which > > breaks the usage of deployment targets such as 10.9.3. > > All Apple doc I can find has deployment targets of the form 10.x or 10.x.0 > (where x is integer, but not only one digit). That is not the case. Do not make that assumption. (In reply to howarth from comment #46) > (In reply to Francois-Xavier Coudert from comment #45) > > (In reply to Jeremy Huddleston Sequoia from comment #42) > > > The committed patch is incorrect. It makes an invalid assumption which > > > breaks the usage of deployment targets such as 10.9.3. > > > > All Apple doc I can find has deployment targets of the form 10.x or 10.x.0 > > (where x is integer, but not only one digit). > > If Jeremy really disagreed on that change, he hasn't acted on it in the > gcc49 MacPorts packaging that he maintains (which still uses the original > proposed patch from > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02428.html). FYI, as far as > llvm-gcc 4.2.1 is concerned, in my fink legacy package for Apple's llvm-gcc > 4.2.1, I used a back port of our patch, > http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/stable/main/finkinfo/ > languages/llvm-gcc42-yosemite.patch. Neither gcc 4.9.2 nor the patched > llvm-gcc 4.2.1 has shown any problems on OS X 10.9.5. I have not fixed the GPL3 ports in MacPorts because I do not read GPL-3 code and thus am not able to fix it. Another MacPorts developer is making the fix for newer versions of gcc.
As this bug is now marked as resolved, I've filed #63810 to address the remaining issues. Lawrence Velázquez <larryv@macports.org> is working on a patch to address the issue.
> Created attachment 33932 [details] > Patch for gcc 4.8 branch (based on gcc 4.8.3) The test results for this 4.8.3 GCC with the above patch are good: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg01016.html
Attachment 33932 [details] should be superseded by attachment 33970 [details] from bug 63810.
Hi guys, sorry for asking such a stupid question here: I wanted to install and use Fortran on my Mac (never used it before) and ran into the problems with compiling described here. I have basically two questions: 1) which one of the patches reported and listed above shall I use? 2) I tried all of them, but I seem to have difficulties implementing them. Someone suggested to go to the appropriate directory where gcc is stored (i.e. SSD1 ▸ Applications ▸ Xcode ▸ Contents ▸ Developer ▸ usr ▸ bin) store the patch file there (as a .diff, right?) and then execute in the terminal patch -p1 < patchfilename.diff then, i get wlan251-121:patch3 Derrick$ patch -p1 < patch.diff can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc |index 196eb3b..d55e200 100644 |--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc |+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc -------------------------- File to patch: i enter gcc, and then i get patching file gcc Hunk #1 FAILED at 835. 1 out of 1 hunk FAILED -- saving rejects to file gcc.rej can't find file to patch at input line 18 Perhaps you used the wrong -p or --strip option? I am really new to all of this... any hint on how to implement one of the patches, and ideally which patch to use, would be very much appreciated. thank you, best, derrick
(In reply to Derrick Kay from comment #53) I've redirected that question to the mailing list (and answered it): https://gcc.gnu.org/ml/fortran/2014-11/msg00088.html
(In reply to Derrick Kay from comment #53) If you just want the gfortran compiler for Yosemite, either install the gcc49 package under the fink (http://www.finkproject.org), MacPorts (http://www.macports.org) or homebrew (http://brew.sh) packaging systems. Also, a stand-alone installation of gfortran for Yosemite is available at http://hpc.sourceforge.net.
Author: fxcoudert Date: Thu Dec 18 20:12:44 2014 New Revision: 218873 URL: https://gcc.gnu.org/viewcvs?rev=218873&root=gcc&view=rev Log: PR target/61407 * config/darwin-c.c (version_as_macro): Added extra 0 for OS X 10.10 and above. * config/darwin-driver.c (darwin_find_version_from_kernel): Removed kernel version check to avoid incrementing it after every major OS X release. (darwin_default_min_version): Avoid static memory buffer. * gcc.dg/darwin-minversion-1.c: Fixed formatting * gcc.dg/darwin-minversion-2.c: Fixed formatting * gcc.dg/darwin-minversion-3.c: Fixed formatting * gcc.dg/darwin-minversion-4.c: Added test for OS X 10.10 Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-4.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/darwin-c.c branches/gcc-4_8-branch/gcc/config/darwin-driver.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-2.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-3.c
This issue appears to have resurfaced on macOS 10.13 using GCC 4.9.4: https://github.com/rvm/rvm/issues/4200#issuecomment-338546674 I'm uncertain whether the reappearance of this issue is something to be handled in GCC, nor whether commenting on this old report is an appropriate way to (re)open the issue. If nothing else, I'm hoping that this comment finds someone who might provide some helpful insight into the nature of the issue or the fix, so that its reappearance can be fixed as well. If it would be better to open a new report, I'd gladly do so. In any case, please advise.
*** Bug 67734 has been marked as a duplicate of this bug. ***