It seems that my smart LD_LIBRARY_HACK outsmarted me. I added LD_LIBRARY_PATH to built libraries to the ebuild to not have to use $ORIGIN or anything like that in RPATH. This way, we could build all the executables with final rpaths while keeping them working in the build directory. However, now it got to me that it means that also system executables are going to use just-built libraries. The effect is that if clang is used to build llvm, it starts to use just-built llvm library that can be incompatible with it.
QA, could you lend a hand? LLVM has a bunch of custom Makefiles on top of autoconf. AFAICS rpath is set only during build-time and files are not re-linked during install. The default RPATH is: $ORIGIN/../lib which is fine for build tree structure but incorrect/not meaningful for install (since we install in $(get_libdir)/llvm). I first replaced that path with the actual install path and used LD_LIBRARY_PATH but it causes issues described above. Just-compiled executables are used throughout the build and tests. What do you suggest? Should I just link with both RPATHs, or use some other hack during compile/test? I'd rather not get too dep hacking the build system. Do we have any kind of tool to strip RPATH off installed files?
chrpath
/var/cvsroot/gentoo-x86/sys-devel/llvm/llvm-3.3-r1.ebuild,v <-- llvm-3.3-r1.ebuild new revision: 1.3; previous revision: 1.2 /var/cvsroot/gentoo-x86/sys-devel/llvm/llvm-9999-r1.ebuild,v <-- llvm-9999-r1.ebuild new revision: 1.4; previous revision: 1.3 Done with chrpath as suggested.
Just out of curiosity: if I adjust the still in tree llvm-3.3-insecure-rpath.patch to apply on top of llvm-3.3-gentoo-install.patch and drop chrpath, llvm-3.3-r1 seems to build fine. How can I tell if whatever is supposed to be broken in such case, really is ?