On 23.01.2008, at 19:58, Chris Espinosa wrote: On Jan 23, 2008, at 8:09 AM, Jens Miltner wrote: Was this issue ever resolved?
We're seeing similar random build failures when building on our unattended build system using xcodebuild (building a whole project hierarchy) on Leopard. Sometimes, the compiler will just error out with an internal error, sometimes it will choke on innocent declarations. Whenever we check the source files, they are ok and building with Xcode works fine. The next time we run xcodebuild, it will usually go beyond the location that caused it to error out and either complete the build or error out in another location. (with no source files touched, since the errors that gcc finds are fake errors).
This behavior seems to increase, i.e. meanwhile we get an error in almost every second build.
Today, we did a clean install of the system on the build machine, but this didn't help at all. We also erased the entire source tree on the build machine, so basically the entire machine was erased and re-installed.
I was wondering whether it might be connected to the use of shared precompiled headers? I had to bump up the shared precompiled header cache size, because meanwhile our collected precompiled headers are ~ 2GB (in a plethora of different files).
I don't think that in our case it's connected to overriding any paths, since at times, the builds will run fine, whereas other times, it fails at random locations.
I can't see any rhyme or reason that would connect: - the OP's issue where Xcode is trying to exec gcc from its private framework's Resources folder when built from xcodebuild - compiler erroring out with an internal error - compiler "choke on innocent declarations"
For the first, what would help is an environment dump of the user account executing the xcodebuild (just execute "set"). It's possible the user environment is setting some environment variable that is causing Xcode to look in the wrong place for the compiler.
For the second case, if the compiler is crashing, follow its instructions and file a bug with the crash log and a preprocessed version of the source file on which it crashed.
Well, this is a problem: These "internal errors" or crashes only ever happen in our unattended builds, and they happen at unpredictable locations. So in essence, while I could provide the crash log, I can't provide a preprocessed version of the source file. If I log in as the same user that runs the unattended builds and open the project in Xcode and compile that single file, it will usually compile just fine. There are cases where I have to clean out the precompiled headers in order to get stuff compiling, but even then, the prec. header corruption only ever happens when the automatic unattended build is running, never when manually compiling from Xcode.
However, I just realized that regarding the environment, I should mention that when the build is running unattended, it's running from an ssh session, so this might well have an influence on the environment and other infrastructure that should not, but might have an effect on xcodebuild / gcc. The environment is definitely a little different, but the difference don't look like they could affect build settings. FWIW, here are the differences:
jens:~ jens$ diff 'bash environment (ssh)' 'bash environment (login)' 0a1 > Apple_PubSub_Socket_Render=/tmp/launch-Yg0OO6/Render 4d4 < BASH_EXECUTION_STRING=set 8a9,10 > COLUMNS=80 > COMMAND_MODE=unix2003 9a12 > DISPLAY=/tmp/launch-QWei72/:0 11a15,17 > HISTFILE=/Users/buildm/.bash_history > HISTFILESIZE=500 > HISTSIZE=500 15a22,23 > LANG=UTF-8 > LINES=24 18c26,27 < MAIL=/var/mail/buildm --- > MAILCHECK=60 > MANPATH=/usr/share/man:/usr/local/share/man:/usr/X11/man 22,23c31,35 < PATH=/usr/bin:/bin:/usr/sbin:/sbin < PPID=85003 --- > PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin > PIPESTATUS=([0]="0") > PPID=85036 > PS1='\h:\W \u\$ ' > PS2='> ' 25a38 > SECURITYSESSIONID=83117f0 27,31c40,46 < SHELLOPTS=braceexpand:hashall:interactive-comments < SHLVL=2 < SSH_CLIENT='87.234.240.210 49828 22' < SSH_CONNECTION='87.234.240.210 49828 87.234.240.236 22' < TERM=dumb --- > SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor > SHLVL=1 > SSH_AUTH_SOCK=/tmp/launch-avxxPK/Listeners > TERM=xterm-color > TERM_PROGRAM=Apple_Terminal > TERM_PROGRAM_VERSION=237 > TMPDIR=/var/folders/qA/qAwo+FydFH8BOLJbU5vBfU+++TM/-Tmp-/ 34c49,50 < _=/bin/bash --- > _=/etc/bashrc > __CF_USER_TEXT_ENCODING=0x1F6:0:0
The additional paths /usr/local/bin and /usr/X11/bin should not have an effect either: (1) there's nothing serious in /usr/local/bin: buildm$ ls -l /usr/local/bin total 240 lrwxr-xr-x 1 root wheel 12 Jan 23 12:17 cvsnt -> /usr/bin/cvs -rwxr-xr-x 1 root wheel 65164 Sep 30 2006 freeze -rwxr-xr-x 1 root wheel 53004 Feb 24 2007 goldin
(2) /usr/X11/bin only contains the standard items - this is a fresh installation of the OS & Developer Tools. The only 3rd party apps installed was cvsnt and Iceberg, both of them don't touch the X11 directories.
(3) These paths are set when logging in via the GUI, i.e. in the automated build processes, these are not in $PATH.
(4) When comparing e.g. the environment dumped out by one of our shell script build phases, these environments match exactly regardless of whether I manually build in Xcode or whether I pick the dumped environment from the unattended build's log (i.e. the one that is run in an ssh session).
Still, I'm pretty convinced, meanwhile, that the ssh login vs. GUI login does make the difference and causes the sporadic/random build failures, but I have no idea where to start looking for a fix / how to reproduce this reliably...
I also still believe, that the underlying problem of all the random errors we see is a precompiled header corruption, but again, I have no idea how to tackle this such that I can either fix our build process or file a bug report that will allow Apple to reproduce the problem. (We've also seen xcodebuild and even bash crash while building our product and I've filed bug reports for these crashes, provided core dumps, logs and backtraces, but none of this is reproducible at will, although it happens every now and then).
For the third case, post the compiler errors (on the "innocent declaration"), preferably both the working and failure cases. Yes, in that case deleting and rebuilding the precompiled header cache might help. But really only in cases where there's a subtle data corruption bug or some bizarre project misconfiguration.
</jum>
|