[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Andrew Pinski changed: What|Removed |Added CC||275438859 at qq dot com --- Comment #58 from Andrew Pinski --- *** Bug 67734 has been marked as a duplicate of this bug. ***
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Ivan D Vasin changed: What|Removed |Added CC||nisavid at gmail dot com --- Comment #57 from Ivan D Vasin --- 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 target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #56 from Francois-Xavier Coudert --- 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
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #55 from howarth at bromo dot med.uc.edu --- (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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #54 from Francois-Xavier Coudert --- (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
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Derrick Kay changed: What|Removed |Added CC||derrick.k at gmx dot de --- Comment #53 from Derrick Kay --- 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
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #52 from Lawrence Velázquez --- Attachment 33932 should be superseded by attachment 33970 from bug 63810.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #51 from Francois-Xavier Coudert --- > 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
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #50 from Jeremy Huddleston Sequoia --- As this bug is now marked as resolved, I've filed #63810 to address the remaining issues. Lawrence Velázquez is working on a patch to address the issue.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #49 from Jeremy Huddleston Sequoia --- (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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #48 from Francois-Xavier Coudert --- Created attachment 33932 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33932&action=edit 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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
Francois-Xavier Coudert changed:
What|Removed |Added
Target||x86_64-apple-darwin14
Status|NEW |RESOLVED
Host||x86_64-apple-darwin14
Resolution|--- |FIXED
Build||x86_64-apple-darwin14
--- Comment #47 from Francois-Xavier Coudert ---
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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 howarth at bromo dot med.uc.edu changed: What|Removed |Added CC||howarth at bromo dot med.uc.edu --- Comment #46 from howarth at bromo dot med.uc.edu --- (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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #45 from Francois-Xavier Coudert --- (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).
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Andrew Pinski changed: What|Removed |Added CC||cloverm at leidos dot com --- Comment #44 from Andrew Pinski --- *** Bug 63685 has been marked as a duplicate of this bug. ***
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #43 from Jeremy Huddleston Sequoia --- Created attachment 33824 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33824&action=edit gcc 4.2 based patch which handles tiny version numbers properly
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Jeremy Huddleston Sequoia changed: What|Removed |Added CC||jeremyhu at macports dot org --- Comment #42 from Jeremy Huddleston Sequoia --- 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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #41 from Francois-Xavier Coudert --- 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
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #40 from Francois-Xavier Coudert --- 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
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #39 from Lawrence Velázquez --- (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).
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #38 from Lawrence Velázquez --- Created attachment 33464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33464&action=edit 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 #include 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
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #37 from Lawrence Velázquez --- Okay, what I said initially was correct. This was the specific change I made. https://gist.github.com/larryv/9b1cd34a34733c10f734
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #36 from Lawrence Velázquez --- (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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #35 from Lawrence Velázquez --- Created attachment 33461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33461&action=edit 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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Lawrence Velázquez changed: What|Removed |Added CC||larryv at macports dot org --- Comment #34 from Lawrence Velázquez --- (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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #33 from James Clarke --- (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_INODE1 > #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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #32 from James Clarke --- (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!
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #31 from Ilya Mikhaltsou --- (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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #30 from Jack Howarth --- 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_INODE1 #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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #29 from James Clarke --- (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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Jack Howarth changed: What|Removed |Added CC||howarth.at.gcc at gmail dot com --- Comment #28 from Jack Howarth --- 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?
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #27 from James Clarke --- Updated patches: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02415.html
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #26 from James Clarke --- 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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #25 from James Clarke --- (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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #24 from Dominyk Tiller --- (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
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #22 from Eric Martin --- 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) --- Comment #23 from Eric Martin --- (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
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #21 from aggrostyle at gmail dot com --- Thank you! It worked perfect last night!
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #20 from James Clarke --- (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).
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #19 from Alexander Bock --- (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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 aggrostyle at gmail dot com changed: What|Removed |Added CC||aggrostyle at gmail dot com --- Comment #18 from aggrostyle at gmail dot com --- 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!
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Alexander Bock changed: What|Removed |Added CC||alexandermbock at gmail dot com --- Comment #17 from Alexander Bock --- (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!
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #16 from James Clarke --- Created attachment 33180 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180&action=edit 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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #15 from James Clarke --- (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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #14 from James Clarke --- The issue with Availability.h has been fixed as of Developer Preview 4, however `all-stage1-target-libsanitizer` still fails with Error 2.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
Dominyk Tiller changed:
What|Removed |Added
CC||dominyktiller at gmail dot com
--- Comment #13 from Dominyk Tiller ---
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?
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Eric Martin changed: What|Removed |Added CC||ericmark26 at gmail dot com --- Comment #12 from Eric Martin --- 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?
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #11 from Eric Gallager --- (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?
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #10 from Ilya Mikhaltsou --- (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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-17 Ever confirmed|0 |1 --- Comment #9 from Manuel López-Ibáñez --- (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
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Ilya Mikhaltsou changed: What|Removed |Added CC||morpheby at gmail dot com --- Comment #8 from Ilya Mikhaltsou --- Created attachment 32949 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32949&action=edit 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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #7 from Andrew Pinski --- 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()
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Andrew Pinski changed: What|Removed |Added CC||denji0k at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 61432 has been marked as a duplicate of this bug. ***
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #5 from Andreas Schwab --- This has nothing to do with evaluation, it's a syntax error.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #4 from Manuel López-Ibáñez ---
(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. "
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #3 from kassafari at gmail dot com --- Alright, reported to apple as well [:
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #2 from Andrew Pinski ---
(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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #1 from Andrew Pinski ---
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)
^
