clang bootstrap broken on darwin10

I found the origin of the build failure. It is the habitually
leaky buildroot in llvm's projects. I have constantly had to deinstall
the prior copies of llvm/clang/llvm-gcc42 before the new builds
consistently complete. The problem seems to be that the llvm Makefiles
allow the previously installed copies of the llvm shared libraries to be
used in later in the builds rather than the newly built copies. I am
amazed that this issue isn't run into more often.
            Jack

I'm not sure what you mean Jack. Can you describe more of what you're doing here?

-Chris

Chris,
   I have fink llvm-clang packaging that builds with...

  $ ../llvm-2.9/configure --prefix=/sw --prefix=/sw --mandir=/sw/share/man --infodir=/sw/share/info --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --with-as=/Developer/usr/bin/as --with-ld=/Developer/usr/bin/ld --with-nm=/Developer/usr/bin/nm --enable-optimized --enable-assertions --enable-pic --enable-targets=host-only

where the build directory, llvm_objdir, is at the same level as the source
directory. The build problems always seem to arise from having a either a previous
release (2.8) or an older svn copy of llvm/clang installed. I believe the problem
is that the shared libs...

     /sw/lib/BugpointPasses.dylib
     /sw/llib/libEnhancedDisassembly.dylib
     /sw/lib/LLVMHello.dylib
     /sw/lib/profile_rt.dylib
     /sw/lib/libLTO.dylib
     /sw/lib/libclang.dylib

from the older installed build of llvm/clang are incorrectly used during the build
of the newer llvm/clang (hence my usage of the term 'leaky buildroot'). I also believe
this problem may even extend to the installed binaries (such as tblgen), where the
older copy may be run instead of that in the buildroot. Note that in fink we set
automatically set...

CPPFLAGS: -I/sw/include
LDFLAGS: -L/sw/lib

during the build. Also /sw/bin is added to the front of PATH so that the tblgen copy is
found first. I suspect that llvm/clang is being lax about enforcing a tight buildroot
to insure that the newly built shared libraries and executables are always those being
used during the build.
           Jack
ps In every case where this problem has arisen, deinstalling the older packages has
eliminated the build problems which is a telltale that this definitely is a leaky
buildroot issue.

Chris,
   Here is the explicit failure. If I have llvm/clang 2.8 installed and attempt to
build llvm/clang svn, the following build failure occurs...

llvm[2]: Linking Release+Asserts executable FileCheck (without symbols)
g++ -I/sw/src/fink.build/llvm-clang-2.9-0/llvm-2.9/include -I/sw/src/fink.build/llvm-clang-2.9-0/llvm-2.9/utils/FileCheck -I/sw/src/fink.build/llvm-clang-2.9-0/llvm_objdir/include -I/sw/src/fink.build/llvm-clang-2.9-0/llvm_objdir/utils/FileCheck -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -L/sw/lib -m64 -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -O3 -Wl,-rpath -Wl,@executable_path/../lib -L/sw/src/fink.build/llvm-clang-2.9-0/llvm_objdir/Release+Asserts/lib -L/sw/src/fink.build/llvm-clang-2.9-0/llvm_objdir/Release+Asserts/lib -Wl,-exported_symbol,_main -o /sw/src/fink.build/llvm-clang-2.9-0/llvm_objdir/Release+Asserts/bin/FileCheck /sw/src/fink.build/llvm-clang-2.9-0/llvm_objdir/utils/FileCheck/Release+Asserts/FileCheck.o -lLLVMSupport \
     -lpthread -lm
Undefined symbols:
  "llvm::sys::Path::eraseFromDisk(bool, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*) const", referenced from:
      llvm::tool_output_file::CleanupInstaller::~CleanupInstaller()in libLLVMSupport.a(raw_ostream.o)
  "llvm::llvm_is_multithreaded()", referenced from:
      llvm::cl::extrahelp::extrahelp(char const*)in libLLVMSupport.a(CommandLine.o)
      llvm::cl::extrahelp::extrahelp(char const*)in libLLVMSupport.a(CommandLine.o)
      (anonymous namespace)::HelpPrinter::operator=(bool)in libLLVMSupport.a(CommandLine.o)
      (anonymous namespace)::HelpPrinter::operator=(bool)in libLLVMSupport.a(CommandLine.o)
      (anonymous namespace)::HelpPrinter::operator=(bool)in libLLVMSupport.a(CommandLine.o)
      llvm::cl::ParseCommandLineOptions(int, char**, char const*, bool)in libLLVMSupport.a(CommandLine.o)
      llvm::install_fatal_error_handler(void (*)(void*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&), void*)in libLLVMSupport.a(ErrorHandling.o)
      llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void (*)(void*)) constin libLLVMSupport.a(ManagedStatic.o)
      llvm::llvm_shutdown() in libLLVMSupport.a(ManagedStatic.o)
  "llvm::sys::Process::FileDescriptorIsDisplayed(int)", referenced from:
      llvm::raw_fd_ostream::is_displayed() const in libLLVMSupport.a(raw_ostream.o)
  "llvm::raw_ostream::write_escaped(llvm::StringRef, bool)", referenced from:
      Pattern::PrintFailureInfo(llvm::SourceMgr const&, llvm::StringRef, llvm::StringMap<llvm::StringRef, llvm::MallocAllocator> const&) constin FileCheck.o
      Pattern::PrintFailureInfo(llvm::SourceMgr const&, llvm::StringRef, llvm::StringMap<llvm::StringRef, llvm::MallocAllocator> const&) constin FileCheck.o
....

Notice that you just blindly link in -lLLVMSupport without any attempt to make certain that it comes from the build directory
and not the installed binaries for llvm/clang.
          Jack

Chris,
   Looking through the Makefile scheme in llvm/clang, I can't find any place where
LDFLAGS is passed -L$PROJ_OBJ_ROOT (which I assume would evaluate out to
-L/sw/src/fink.build/llvm-clang-2.8-0/llvm_objdi/Release+Asserts/lib. I assume this needs to be
placed in front of any LDFLAGS passed to the build so that you end up with...
-L/sw/src/fink.build/llvm-clang-2.8-0/llvm_objdi/Release+Asserts/lib -L/sw/lib such
that the newly built libLLVMSupport.a is found before /sw/lib/libLLVMSupport.a from
the older llvm/clang installation.
          Jack

Chris,
   The problem seems to be that LD.Flags in Makefile.rules, which defines...

LD.Flags += -L$(LibDir) -L$(LLVMLibDir)

isn't being placed ahead of LDFLAGS in the build. I don't quite see how this
can be easily fixed given that prepending isn't available. It seems that
LDFLAGS passed to the build need to be stored in another variable and
LDFLAGS cleared. Then the build can place this stored LDFLAGS after the
one that Makefile.rules sets up with LD.Flags.
           Jack

Chris,
   The following patch eliminates the build problems for llvm svn
when llvm 2.8 is installed...

Index: Makefile.rules

Yeah. That seems reasonable.

Can you resend your patch to me as an attachment?

Thanks!

-eric