Bug 61407 - Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
Summary: Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 61432 63685 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-06-04 05:41 UTC by kassafari
Modified: 2017-10-23 07:15 UTC (History)
20 users (show)

See Also:
Host: x86_64-apple-darwin14
Target: x86_64-apple-darwin14
Build: x86_64-apple-darwin14
Known to work:
Known to fail:
Last reconfirmed: 2014-06-17 00:00:00


Attachments
make log (32.85 KB, text/plain)
2014-06-04 05:41 UTC, kassafari
Details
Patch to compile gcc on OS X 10.10 Yosemite (2.68 KB, patch)
2014-06-17 09:08 UTC, Ilya Mikhaltsou
Details | Diff
Patch For GCC 4.9.1 On Yosemite (1.12 KB, patch)
2014-07-24 13:33 UTC, James Clarke
Details | Diff
MacPorts log from a failed attempt to build libgcc @4.9.1_0 (x86_64) (82 bytes, text/plain)
2014-09-08 21:56 UTC, Lawrence Velázquez
Details
Corrected dirent patch (600 bytes, patch)
2014-09-09 20:59 UTC, Lawrence Velázquez
Details | Diff
gcc 4.2 based patch which handles tiny version numbers properly (908 bytes, patch)
2014-10-27 19:19 UTC, Jeremy Huddleston Sequoia
Details | Diff
Patch for gcc 4.8 branch (based on gcc 4.8.3) (2.12 KB, patch)
2014-11-10 20:29 UTC, Francois-Xavier Coudert
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description kassafari 2014-06-04 05:41:45 UTC
Created attachment 32886 [details]
make log

Will not build on latest OS X and Xcode... Attaching log...
Comment 1 Andrew Pinski 2014-06-04 05:54:20 UTC
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)
                                            ^
Comment 2 Andrew Pinski 2014-06-04 06:05:21 UTC
(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.
Comment 3 kassafari 2014-06-04 07:20:55 UTC
Alright, reported to apple as well [:
Comment 4 Manuel López-Ibáñez 2014-06-04 08:40:40 UTC
(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. "
Comment 5 Andreas Schwab 2014-06-04 08:52:20 UTC
This has nothing to do with evaluation, it's a syntax error.
Comment 6 Andrew Pinski 2014-06-06 19:03:23 UTC
*** Bug 61432 has been marked as a duplicate of this bug. ***
Comment 7 Andrew Pinski 2014-06-06 19:06:34 UTC
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()
Comment 8 Ilya Mikhaltsou 2014-06-17 09:08:58 UTC
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.
Comment 9 Manuel López-Ibáñez 2014-06-17 09:47:54 UTC
(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
Comment 10 Ilya Mikhaltsou 2014-06-17 10:02:04 UTC
(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.
Comment 11 Eric Gallager 2014-06-20 12:27:40 UTC
(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?
Comment 12 Eric Martin 2014-06-28 04:19:52 UTC
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?
Comment 13 Dominyk Tiller 2014-07-20 16:23:50 UTC
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?
Comment 14 James Clarke 2014-07-21 21:41:47 UTC
The issue with Availability.h has been fixed as of Developer Preview 4, however `all-stage1-target-libsanitizer` still fails with Error 2.
Comment 15 James Clarke 2014-07-21 21:43:01 UTC
(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.
Comment 16 James Clarke 2014-07-24 13:33:58 UTC
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.
Comment 17 Alexander Bock 2014-07-24 15:27:34 UTC
(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!
Comment 18 aggrostyle 2014-07-30 23:06:26 UTC
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!
Comment 19 Alexander Bock 2014-07-31 02:12:17 UTC
(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.
Comment 20 James Clarke 2014-07-31 10:08:47 UTC
(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).
Comment 21 aggrostyle 2014-07-31 12:34:28 UTC
Thank you! It worked perfect last night!
Comment 22 Eric Martin 2014-08-01 01:49:31 UTC
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 Eric Martin 2014-08-02 16:12:48 UTC
(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
Comment 24 Dominyk Tiller 2014-08-22 16:06:44 UTC
(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
Comment 25 James Clarke 2014-08-25 15:46:52 UTC
(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.
Comment 26 James Clarke 2014-08-25 18:17:11 UTC
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.
Comment 27 James Clarke 2014-08-26 16:04:51 UTC
Updated patches: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02415.html
Comment 28 Jack Howarth 2014-08-26 17:28:14 UTC
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?
Comment 29 James Clarke 2014-08-26 18:18:16 UTC
(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.
Comment 30 Jack Howarth 2014-08-26 19:38:59 UTC
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.
Comment 31 Ilya Mikhaltsou 2014-08-26 20:41:24 UTC
(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.
Comment 32 James Clarke 2014-08-27 18:01:49 UTC
(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!
Comment 33 James Clarke 2014-08-27 18:05:31 UTC
(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.
Comment 34 Lawrence Velázquez 2014-09-08 21:41:13 UTC
(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.
Comment 35 Lawrence Velázquez 2014-09-08 21:56:07 UTC
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.
Comment 36 Lawrence Velázquez 2014-09-08 23:03:05 UTC
(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.
Comment 37 Lawrence Velázquez 2014-09-09 05:08:15 UTC
Okay, what I said initially was correct. This was the specific change I made.

https://gist.github.com/larryv/9b1cd34a34733c10f734
Comment 38 Lawrence Velázquez 2014-09-09 20:59:12 UTC
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
Comment 39 Lawrence Velázquez 2014-09-10 00:36:33 UTC
(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).
Comment 40 Francois-Xavier Coudert 2014-09-14 08:06:16 UTC
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
Comment 41 Francois-Xavier Coudert 2014-09-29 18:41:29 UTC
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
Comment 42 Jeremy Huddleston Sequoia 2014-10-27 19:18:05 UTC
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.
Comment 43 Jeremy Huddleston Sequoia 2014-10-27 19:19:29 UTC
Created attachment 33824 [details]
gcc 4.2 based patch which handles tiny version numbers properly
Comment 44 Andrew Pinski 2014-10-30 01:09:30 UTC
*** Bug 63685 has been marked as a duplicate of this bug. ***
Comment 45 Francois-Xavier Coudert 2014-11-10 16:34:02 UTC
(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).
Comment 46 Jack Howarth 2014-11-10 16:55:35 UTC
(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.
Comment 47 Francois-Xavier Coudert 2014-11-10 20:27:08 UTC
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.
Comment 48 Francois-Xavier Coudert 2014-11-10 20:29:13 UTC
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.
Comment 49 Jeremy Huddleston Sequoia 2014-11-11 01:58:15 UTC
(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.
Comment 50 Jeremy Huddleston Sequoia 2014-11-11 02:01:32 UTC
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.
Comment 51 Francois-Xavier Coudert 2014-11-11 08:18:28 UTC
> 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
Comment 52 Lawrence Velázquez 2014-11-14 09:39:29 UTC
Attachment 33932 [details] should be superseded by attachment 33970 [details] from bug 63810.
Comment 53 Derrick Kay 2014-11-15 14:26:37 UTC
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
Comment 54 Francois-Xavier Coudert 2014-11-15 14:54:22 UTC
(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
Comment 55 Jack Howarth 2014-11-15 15:52:16 UTC
(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.
Comment 56 Francois-Xavier Coudert 2014-12-18 20:13:16 UTC
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
Comment 57 Ivan D Vasin 2017-10-23 07:15:23 UTC
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.