On Jan 23, 2008, at 8:09 AM, Jens Miltner wrote: I recently switch from XCode 2 to XCode 3 without problems. Within XCode every project can be compiled,linked and products are working. I often use xcodebuild in the terminal to build sequences of different projects. When building a project, any compilation step always fails, because of a fake gcc:
xcodebuild Checking Dependencies...
CompileC build/IcebergRoot.build/Debug/IcebergRoot.build/Objects-normal/i386/IcebergAbstractClass.o /Volumes/Data/Users/boesch/Documents/Work/Ice/Libs/IcebergRoot/IcebergAbstractClass.c normal i386 c++ com.apple.compilers.gcc.4_0 cd /Volumes/Data/Users/boesch/Documents/Work/Ice/Libs/IcebergRoot /Developer/Library/PrivateFrameworks/DevToolsCore.framework/Resources/gcc -x c++ -arch i386 -p...
error: can't exec '/Developer/Library/PrivateFrameworks/DevToolsCore.framework/Resources/gcc' (No such file or directory) ** BUILD FAILED **
Any clues, why CompileC spits out this non-existing path ? Who controls CompileC ? Other build steps seem to work fine.
I did reinstall XC3, but got the same result.
Can you post your build settings from the project and target level? If a clean reinstall doesn't solve the problem, I begin to wonder if you are unknowingly overriding the path to gcc.
Does this happen with a new user?
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.
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.
Chris |