Summary: | sys-devel/clang-9999 - clang: error while loading shared libraries: libLLVM-3.4svn.so: cannot open shared object file: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Marcin Mirosław <bug> |
Component: | [OLD] Development | Assignee: | Bernard Cafarelli <voyageur> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | 0xd34df00d, mgorny, my, nikoli, paolo.pedroni, ryao |
Priority: | Normal | Keywords: | REGRESSION |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 477432 | ||
Bug Blocks: | |||
Attachments: | emerge --info on my system |
Description
Marcin Mirosław
2013-06-18 12:08:39 UTC
Hmm, looks like they finally stepped on their own mine. I will re-merge it today and see if I can reproduce it. I'm afraid I can't reproduce this. Could you try updating it again? Maybe they fixed it in svn already. I just reemerged llvm&clang again, clang is at 184308, llvm is at 184306. It doesn't solve my problem. Diff beetwen `equery f llvm` old an new is: diff -u llvm-dotych llvm-new --- llvm-dotych 2013-06-19 17:00:09.093222287 +0200 +++ llvm-new 2013-06-19 17:36:06.953614355 +0200 @@ -428,6 +428,7 @@ /usr/include/llvm/Object/Error.h /usr/include/llvm/Object/MachO.h /usr/include/llvm/Object/MachOFormat.h +/usr/include/llvm/Object/MachOUniversal.h /usr/include/llvm/Object/ObjectFile.h /usr/include/llvm/Object/RelocVisitor.h /usr/include/llvm/Object/YAML.h So libLLVM-3.4svn.so is still in the same place. # equery f llvm|grep libLLVM-3.4svn.so /usr/lib64/llvm/libLLVM-3.4svn.so Well, wasn't libLLVM always there? I was pretty sure about it a minute ago but now I'm in doubt. In any case, mesa has had issues finding libLLVM for a while already and it seems that clang finally joined it. I had a work-around for it in /etc/ld.so.conf.d/, that's why it worked for me. Sorry for making you rebuild it unnecessarily. @voyageur, I guess we may take the easy way and install such a work-around in /etc/ld.so.conf.d for now or just start installing LLVM into /usr/lib* like cmake does. I looked into very old backup (6.11.2012) and I can see: /usr/lib/llvm/libLLVM-3.2svn.so I chrooted inside and I did use strace: # strace -s 800 clang 2>&1|grep libLLVM open("/usr/lib64/llvm/tls/x86_64/libLLVM-3.2svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/llvm/tls/libLLVM-3.2svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/llvm/x86_64/libLLVM-3.2svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/llvm/libLLVM-3.2svn.so", O_RDONLY|O_CLOEXEC) = 3 It's ok. Now I;m launching strace on current installation: # strace -s 800 clang 2>&1|grep libLLVM open("/usr/bin/../lib/tls/x86_64/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/bin/../lib/tls/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/bin/../lib/x86_64/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/bin/../lib/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/tls/x86_64/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/tls/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/x86_64/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/x86_64/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/x86_64/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/libLLVM-3.4svn.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) writev(2, [{"clang", 5}, {": ", 2}, {"error while loading shared libraries", 36}, {": ", 2}, {"libLLVM-3.4svn.so", 17}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10clang: error while loading shared libraries: libLLVM-3.4svn.so: cannot open shared object file: No such file or directory Could clang binary had hardcoded paths to shared library? On diffrent host I have clang/llvm at rev.183607, I'm getting "error while loading shared libraries" also Indeed, since we enabled shared library, libLLVM was always there. Maybe a faulty llvm-config output (or changed since 3.3 release)? I need to test with -9999 3.3 has correct rpath on clang: % chrpath /usr/bin/clang /usr/bin/clang: RPATH=$ORIGIN/../lib:/usr/lib64/llvm I can confirm this on clang and llvm emerged just now. Created attachment 351732 [details]
emerge --info on my system
I have been affected by this too, but I was not paying too much attention, so I thought that I had built clang in a manner that was out-of-sync with LLVM. With that said, this sounds like an upstream issue. Someone will need to start building older versions of LLVM and Clang via ESVN_REVISION to find out which upstream change broke this on us. I can try to find problematic revision. I checked using such command: ESVN_REVISION=182559 emerge -qv1 llvm clang Last working revision: 182558 I did diff beetwen list of files, no difference. r182559 | rafael | 2013-05-23 04:53:22 +0200 (czw) | 5 linii Remove redundant rpath. These are not needed since we added the $ORIGIN based rpath. This is not only clang bug llvm stuff (like llc) too Bug in llvm-9999.ebuild in src_prepare "Fixing rpath and CFLAGS" have wrong substitute sed -e "s,\$(RPATH) -Wl\,'\$\$ORIGIN/../lib',\$(RPATH) -Wl\,""${EPREFIX}"/usr/$(get_libdir)/${PN}, \ must fix this bug but may be better fix all $$ORIGIN $$ORIGIN it's like 'executable_path' get at runtime we can replace this, or replace all path which have this $$ORIGIN/../lib to $$ORIGIN/../$(get_libdir)/${PN} as example I'm working on it right now. I'll convert all the seds into epatch+sed which should be much safer. I've replaced all the sed statements with patches in llvm-9999-r1::mgorny. I'll backport it to -3.3-r1::mgorny soon; in the meantime, feel free to test it. Good news is that it fixes clang. Bad news is that LLVM is still broken. I wonder if RPATH was added to llvm-config somehow implicitly or explicitly. (In reply to Michał Górny from comment #17) > Good news is that it fixes clang. Bad news is that LLVM is still broken. I > wonder if RPATH was added to llvm-config somehow implicitly or explicitly. Sorry, I meant mesa/vdpau is broken. I've tried llvm-r1 and it works for me. And it's just one package instead of two, I like it:) I've backported the patch to 3.3-r1::mgorny as well but =llvm-3.3-r1[clang] fails to build. I have no idea why, I'd appreciate if someone could nail it down. In the meantime, trying to build [-clang]. Ok, 3.3 backport is fixed in ::mgorny now. It seems that 3.3 requires $ORIGIN in rpath to build. I'd like someone to confirm that 9999 doesn't require it and it's not just a coincidence due to svn build. This involves 3.3 installing files with insecure rpaths but I don't know if it's worth fighting it at the point. This should be fixed in -3.3-r1 and -9999. |