tree f61765335c5e739a57fb03fd3b5e6fcfdf4a53b8
parent 60a68d2f6498c7aae0f6fbfc3009f3c4edfa9511
author Bill Wendling <isanbard@gmail.com> 1320302869 +0000
committer Bill Wendling <isanbard@gmail.com> 1320302869 +0000

Merging r143460:
------------------------------------------------------------------------
r143460 | baldrick | 2011-11-01 06:38:01 -0700 (Tue, 01 Nov 2011) | 20 lines

On Debian testing and recent Ubuntu systems llvm-ld fails to find libc,
causing every test in the nightly testsuite to fail.  But llvm-ld is only
using libc to work out which symbols to internalize, not for linking with
it.  How can libc effect which symbols are internalized?  I can see two
possibilities: either libc makes use of a function defined in the bitcode
(which it clearly doesn't) or a weak function occurs both in the bitcode
and in libc (in which case using the bitcode's copy should be OK).  Thus
there doesn't seem to any point in looking at libc and comparable system
libraries (eg: libstdc++) when internalizing, and this is confirmed by my
testing: not passing -lc or $(LIBS) when invoking llvm-ld doesn't cause
any failures.  So a simple fix for the Debian issue would be simply not
to pass them to llvm-ld.  But then the question arises: why use llvm-ld
at all rather than "opt -std-link-opts"?  This patch goes all the way
and drops llvm-ld in favour of "opt -std-link-opts".  It also removes
some apparently pointless Makefile rules, which I suspect exist because
llvm-ld produces two output files, X (a script) and X.bc (the bitcode).
With this llvm-ld is not used by the nightly testsuite at all.  It works
for me, but since I don't know the nightly testsuite infrastructure well
I may have broken something, so please review.

------------------------------------------------------------------------

llvm-svn: 143611