Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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: 143460
- Loading branch information