Opened 5 years ago

Closed 5 years ago

#18156 closed defect (fixed)

XCode 6.3 broken

Reported by: vbraun Owned by:
Priority: major Milestone: sage-6.7
Component: build Keywords:
Cc: dimpase Merged in:
Authors: Buck Evan Reviewers: John Palmieri, Dima Pasechnik
Report Upstream: N/A Work issues:
Branch: a3ac459 (Commits) Commit: a3ac4598f72ca7a9d67bfa59eb9f854a92ecfa74
Dependencies: Stopgaps:

Description

http://stackoverflow.com/questions/29529455/missing-c-header-debug-after-updating-osx-command-line-tools-6-3

Even if you hack in the missing(?) __debug header, the gcc bootstrap in Sage will fail.

Change History (24)

comment:1 Changed 5 years ago by buck

I didn't run into this. Was it because I wasn't doing a debug build?

comment:2 Changed 5 years ago by vbraun

This is without doing anything special. It might only be triggered if you only have command line tools without the gui xcode part. Though with the gui xcode stuff you just hit other bugs.

comment:3 Changed 5 years ago by jhpalmieri

Xcode 6.3.1 was released, but gcc still won't build for me. (This is with both the gui part and the command line tools installed.)

Version 0, edited 5 years ago by jhpalmieri (next)

comment:4 follow-up: Changed 5 years ago by fbissey

Just tried a clean with sources that I currently have around on my mac (6.6.beta5) and it failed to build gcc too, not during what I would call bootstraping, but I am guessing that's what you are talking about because of the message.

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/asan.o differs
gcc/attribs.o differs
gcc/bitmap.o differs
gcc/c/c-decl.o differs
gcc/cfg.o differs
gcc/coverage.o differs
gcc/cp/class.o differs
gcc/cp/semantics.o differs
gcc/cp/tree.o differs
gcc/dse.o differs
gcc/dwarf2out.o differs
gcc/except.o differs
gcc/fortran/trans-common.o differs
gcc/ggc-common.o differs
gcc/ipa-profile.o differs
gcc/ira-color.o differs
gcc/ira-costs.o differs
gcc/loop-unroll.o differs
gcc/lto-streamer-in.o differs
gcc/lto-streamer-out.o differs
gcc/passes.o differs
gcc/plugin.o differs
gcc/postreload-gcse.o differs
gcc/statistics.o differs
gcc/trans-mem.o differs
gcc/tree-cfg.o differs
gcc/tree-eh.o differs
gcc/tree-ssa-ccp.o differs
gcc/tree-ssa-coalesce.o differs
gcc/tree-ssa-dom.o differs
gcc/tree-ssa-live.o differs
gcc/tree-ssa-loop-ivopts.o differs
gcc/tree-ssa-phiopt.o differs
gcc/tree-ssa-pre.o differs
gcc/tree-ssa-reassoc.o differs
gcc/tree-ssa-threadupdate.o differs
gcc/tree-ssa-uncprop.o differs
gcc/tree-vectorizer.o differs
gcc/valtrack.o differs
gcc/vtable-verify.o differs
make[5]: *** [compare] Error 1
make[4]: *** [stage3-bubble] Error 2
make[3]: *** [all] Error 2

Since when is a difference between stage 2 and stage 3 an automatic failure?

comment:5 follow-up: Changed 5 years ago by vbraun

I've seen exactly the same when bootstrapping gcc with Xcode 6.3.

There is a workaround at https://github.com/Homebrew/homebrew/pull/38596

comment:6 in reply to: ↑ 5 Changed 5 years ago by fbissey

Replying to vbraun:

I've seen exactly the same when bootstrapping gcc with Xcode 6.3.

There is a workaround at https://github.com/Homebrew/homebrew/pull/38596

Yes that works. I added to GCC_CONFIG in the block for darwin-14 and it did go through.

comment:7 in reply to: ↑ 4 Changed 5 years ago by jdemeyer

Replying to fbissey:

Since when is a difference between stage 2 and stage 3 an automatic failure?

Since always that I can remember...

comment:8 follow-up: Changed 5 years ago by jhpalmieri

It works for me, too. With only the 6.3.1 command line tools installed (not the gui Xcode app), gcc fails without the workaround, builds with it. R fails (#18254), so if I also fake the installation of R and rpy2 by touching the appropriate files in local/var/lib/sage/installed, the rest of Sage builds and passes most tests. The only failures are related to the absence of R and rpy2.

For the record, I used this change:

  • build/pkgs/gcc/spkg-install

    diff --git a/build/pkgs/gcc/spkg-install b/build/pkgs/gcc/spkg-install
    index 54ec8a5..72ad913 100755
    a b if { uname -sr | grep 'Darwin 14\.' ;} &>/dev/null; then 
    7979    else
    8080        echo "Warning: header /usr/include/dispatch/object.h not found, not applying fix."
    8181    fi
     82    # Use 'bootstrap-debug' build configuration to force stripping of object
     83    # files prior to comparison during bootstrap (broken by Xcode 6.3).
     84    GCC_CONFIGURE="--with-build-config=bootstrap-debug $GCC_CONFIGURE"
    8285fi
    8386
    8487# On OSX: isl/cloog libraries are almost certainly from Homebrew and won't work

comment:9 Changed 5 years ago by dimpase

  • Cc dimpase added
  • Milestone changed from sage-6.6 to sage-6.7

comment:10 in reply to: ↑ 8 ; follow-up: Changed 5 years ago by dimpase

Replying to jhpalmieri:

It works for me, too. With only the 6.3.1 command line tools installed (not the gui Xcode app), gcc fails without the workaround, builds with it. R fails (#18254), so if I also fake the installation of R and rpy2 by touching the appropriate files in local/var/lib/sage/installed, the rest of Sage builds and passes most tests. The only failures are related to the absence of R and rpy2.

For the record, I used this change:

  • build/pkgs/gcc/spkg-install

    diff --git a/build/pkgs/gcc/spkg-install b/build/pkgs/gcc/spkg-install
    index 54ec8a5..72ad913 100755
    a b if { uname -sr | grep 'Darwin 14\.' ;} &>/dev/null; then 
    7979    else
    8080        echo "Warning: header /usr/include/dispatch/object.h not found, not applying fix."
    8181    fi
     82    # Use 'bootstrap-debug' build configuration to force stripping of object
     83    # files prior to comparison during bootstrap (broken by Xcode 6.3).
     84    GCC_CONFIGURE="--with-build-config=bootstrap-debug $GCC_CONFIGURE"
    8285fi
    8386
    8487# On OSX: isl/cloog libraries are almost certainly from Homebrew and won't work

should we check for the version of Xcode, too? (this patch is not needed on Xcode <= 6.2)

comment:11 in reply to: ↑ 10 ; follow-up: Changed 5 years ago by jhpalmieri

Replying to dimpase:

should we check for the version of Xcode, too? (this patch is not needed on Xcode <= 6.2)

Probably. Do you know a good way to do that? (It would probably be best, in fact, to check for the missing feature rather than a specific version number.)

comment:12 in reply to: ↑ 11 Changed 5 years ago by dimpase

Replying to jhpalmieri:

Replying to dimpase:

should we check for the version of Xcode, too? (this patch is not needed on Xcode <= 6.2)

Probably. Do you know a good way to do that?

xcodebuild -version | grep XCode

will output something like

XCode a.b.c

So this is just a bit of shell scripting. If you like I can do this.

(It would probably be best, in fact, to check for the missing feature rather than a specific version number.)

well, this sounds like adding a check to gcc configure script; while doable, it does not seem like worth the effort to me.

comment:13 Changed 5 years ago by jhpalmieri

Unfortunately this won't work. If you just have the command-line tools installed, not Xcode.app, you will see

$ xcodebuild -version
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance

The command xcode-select -version seems to output

xcode-select version 2339.

for both 6.2 and 6.3.1. I tried looking for the string "6.3.1" in the command-line tools directory, but couldn't find anything, nor did I find any obviously useful differences between the directories for 6.2 and 6.3.1 (not that I really know what I'm looking for). They have different versions of git, so we could look at something like

$ `xcode-select -p`/usr/bin/git --version

but this is pretty indirect.

comment:14 Changed 5 years ago by jhpalmieri

We could do the same but with gcc:

$ `xcode-select -p`/usr/bin/gcc --version 2> /dev/null | grep 'Apple LLVM version'
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)

With Xcode 6.2, we get "Apple LLVM version 6.0", and with Xcode 6.3.1, we get 6.1.0.

comment:15 follow-up: Changed 5 years ago by buck

Is there any drawback to doing this invariantly, without regard fire xcode version? If not, the special case is undesirable. It creates new edge cases for bugs for users and testers.

comment:16 in reply to: ↑ 15 Changed 5 years ago by jhpalmieri

Replying to buck:

Is there any drawback to doing this invariantly, without regard fire xcode version?

Do you mean always using GCC_CONFIGURE="--with-build-config=bootstrap-debug $GCC_CONFIGURE" on OS X?

comment:17 Changed 5 years ago by fbissey

Like buck I am all to keep it simple. We already have a few blanket statements for 10.10, we should just add it there. I am expecting the percentage of people staying behind to be low. You need a specific reason not to upgrade rather than the reverse (although I have to agree that apple continuously breaking things is a good motivation).

comment:18 follow-up: Changed 5 years ago by buck

I actually meant for all OSX, as jhp was asking.

Putting as much configuration outside of if-statements as possible means less edges to the state space; it makes it more likely that everyone can reproduce the same set of bugs.

comment:19 in reply to: ↑ 18 Changed 5 years ago by dimpase

Replying to buck:

I actually meant for all OSX, as jhp was asking.

Putting as much configuration outside of if-statements as possible means less edges to the state space; it makes it more likely that everyone can reproduce the same set of bugs.

indeed, particularly given Apple's non-support of anything older than OSX 10.10, I see the point; it could also happen that they eventually push the same broken llvm version into XCode for older OSX versions...

comment:20 Changed 5 years ago by buck

  • Branch set to u/buck/yosemite-gcc-bootstrap

comment:21 Changed 5 years ago by buck

  • Commit set to a3ac4598f72ca7a9d67bfa59eb9f854a92ecfa74
  • Status changed from new to needs_review

New commits:

a3ac459strip gcc bootstrap in osx: #18156

comment:22 Changed 5 years ago by dimpase

  • Status changed from needs_review to positive_review

LGTM

comment:23 Changed 5 years ago by dimpase

  • Authors set to Buck Evan
  • Reviewers set to John Palmieri, Dima Pasechnik

comment:24 Changed 5 years ago by vbraun

  • Branch changed from u/buck/yosemite-gcc-bootstrap to a3ac4598f72ca7a9d67bfa59eb9f854a92ecfa74
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.