Creating release candidate final from release_30 branch
llvm-svn: 145351
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
1 file changed
