make[3]: *** No rule to make target
`/Volumes/Builds/llvm/runtime/GCCLibraries/crtend/
BytecodeObj/crtend.bc', needed by
`/Volumes/Builds/llvm/runtime/GCCLibraries/crtend/
BytecodeObj/comp_main.bc'.  Stop.
make[2]: *** [crtend/.makeall] Error 2
make[1]: *** [GCCLibraries/.makeall] Error 2

Are you sure that the path to the C front-end was correctly specified when you
configured your LLVM tree?  In your llvm/Makefile.config file, make sure that
$LLVMGCCDIR/bin/gcc  resolves to the proper executable.

-Chris

Yes.  Its made everything okay up until this point in the build.  I also tried
it on the cvs version.  
Breaks at the same spot.

Hrm, that's really strange.  Are you building with SRCDIR != OBJDIR?  If so, you
might want to try building into the source tree.  I've looked at the rules, and
they seem ok, but perhaps the vpath is not picking up the source file correctly.
 Can you post the version of gmake you are using and how you configured your
tree?   John, do you have any ideas what could be causing this? 

Thanks,

-Chris

Created an attachment (id=64) [details]
Configuration

GNU Make version 3.79, by Richard Stallman and Roland McGrath.

I included the makefile.config.

The sources are at /Volumes/Stuff/llvm/llvm
The objs at /Volumes/Builds/llvm
An the Darwin binaries at /Volumes/Stuff/llvm/cfrontend-powerpc-apple-darwin7.0.0/llvm-gcc

Mr. Laskey,

Would you be able to try to build the directory with the following command:

gmake -d VERBOSE=1

...and post the output here.  That may also shed some light on the problem.

Thanks.

I'm currently building with SIRDIR == OBJDIR.  If that bails I'll do the
VERBOSE=1.

And Chris, the name is Jim ;-)  You can e-mail me directly for digressions. 
Cheers.

Brian is currently rebuilding the tree on his G5 (with OBJDIR != SRCDIR) so I'll
let you know if and when we can reproduce the problem.  He's running the same
gmake version as well.

-Chris

Created an attachment (id=65) [details]
Make verbose dump (.tgz)

OBJDIR == SRCDIR fails as well.

I suspect that I need a make setting to auto mkdirs.  But I don't recall the setting off the top of my 
head.

I know what the problem is:

The LLVMGCCARCH variable in your Makefile.config file is "incorrect."  By that,
I mean that it doesn't match what is in our pre-compiled llvm-gcc binary for
MacOS X.

If you modify Makefile.config so that LLVMGCCARCH is set to:

powerpc-apple-darwin7.0.0

...that should fix the problem.

I was unable to reproduce this on my Mac.  However, I'm guessing that you are
getting this error because your updated Darwin kernel is version 7.2.0 and I was
running 7.0.0 at the time I built the LLVM 1.1 release C/C++ front-end package.
I suggest trying John's workaround.

That does it.

Ok, now the question is, how do we robustly fix this?

The only reason for the target string is to have the makefiles rebuild bytecode
files if the C front-end is changed.  This is nice, but not worth breaking the
build for.

Could we have the configure script run 'llvmgcc -v' and pull out the target
string to use?  Alternatively, we could just have LCC1 be defined in terms of
$(wildcard), so that it is empty if it does not exist.

What do the build experts think?  :)

-Chris

Could we have it depend on the output of
llvm-gcc --print-prog-name=cc1
(or the empty string if that fails?)

That sounds like an excellent idea.  I didn't know that feature existed. :) 
From that, we could have the configure script robustly figure out the target string.

I'm downgrading this bug to critical, because there is a work-around.

-Chris

I'll try to get Brian's fix in place either today or tomorrow.

I committed the fix, which was only partially complete in the version I e-mailed
to Chris. It seems to be working. I tested it on the Intel machines by doing a
normal configure, and also by doing a configure --with-llvmgccdir=/tmp (to make
it fail to find llvm-gcc). In the latter case, it sets LCC and LCC1XX to empty
strings.

Great, sounds good.  Do you want to close this PR then?  Also, please update the
release notes  :)

-Chris

OK, closing this one.