Opened 8 years ago
Closed 8 years ago
#51542 closed defect (fixed)
clang-3.8 and clang-3.9 fail to function due to rpath
| Reported by: | kenneth.f.cunningham@… | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.3.4 |
| Keywords: | Cc: | larryv (Lawrence Velázquez) | |
| Port: | clang-3.8 |
Description
when compiling simple 'hello world' app
#include <stdio.h>
int main() {
printf("hello world\n");
return 0;
}
clang-3.8 fails with
user$ clang hello.c -o hello dyld: Library not loaded: @rpath/libLLVM.dylib Referenced from: /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib Reason: image not found clang: error: unable to execute command: Trace/BPT trap clang: error: linker command failed due to signal (use -v to see invocation)
same error happens with clang-3.9, I noticed.
code compiles correctly and llvm tools work with clang 3.7 and 3.4 selected.
It appears the clang 3.8 and 3.9 rpath is not finding the runtime libraries. I'm not certain if this is due to how they were compiled, or something different in my configuration that would affect only the newer versions of clang.
(Clang-3.8 was installed precompiled. Clang-3.9 was installed from source). I'm on 10.6.8.
Change History (19)
comment:1 Changed 8 years ago by kenneth.f.cunningham@…
comment:2 Changed 8 years ago by mf2k (Frank Schima)
| Cc: | larryv@… added; jeremyhu@… removed |
|---|---|
| Owner: | changed from macports-tickets@… to jeremyhu@… |
comment:3 Changed 8 years ago by kenneth.f.cunningham@…
btw, the missing library is actually present in the correct location for both llvm-3.8 (and also for llvm-3.9), so it seems to be just the rpath configuration I have for these two versions. Please excuse my obviously incomplete knowledge of clang and llvm configuration.
user$ ls -la /opt/local/libexec/llvm-3.8/lib/libLLVM.dylib -rwxr-xr-x 1 root admin 35708340 12 Mar 16:07 /opt/local/libexec/llvm-3.8/lib/libLLVM.dylib user$ ls -la /opt/local/libexec/llvm-3.9/lib/libLLVM.dylib -rwxr-xr-x 1 root admin 54732472 29 May 20:12 /opt/local/libexec/llvm-3.9/lib/libLLVM.dylib
comment:4 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
On my copy, I see:
~ $ otool -l /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib | grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 32
path @loader_path (offset 12)
--
cmd LC_RPATH
cmdsize 40
path @executable_path/../lib (offset 12)
Arguably, the second one is extraneous for the dylib. The first one should be resolving it.
Are those not set for you?
What is the output when you run with DYLD_PRINT_RPATHS=1
comment:5 Changed 8 years ago by kenneth.f.cunningham@…
Thanks for looking. Wish I had your knowledge. I get similar otool output to what you get
$ port select --list clang
Available versions for clang:
mp-clang-3.4
mp-clang-3.7
mp-clang-3.8 (active)
mp-clang-3.9
none
$ port select --list llvm
Available versions for llvm:
mp-llvm-3.4
mp-llvm-3.7
mp-llvm-3.8 (active)
mp-llvm-3.9
none
$ clang hello.c -o hello
dyld: Library not loaded: @rpath/libLLVM.dylib
Referenced from: /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib
Reason: image not found
clang: error: unable to execute command: Trace/BPT trap
clang: error: linker command failed due to signal (use -v to see invocation)
$ otool -l /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib | grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 32
path @loader_path (offset 12)
--
cmd LC_RPATH
cmdsize 40
path @executable_path/../lib (offset 12)
the DYLD_PRINT_RPATHS=1 was not too satisfying - I suspect this might not be available on snowleopard as I couldn't find it in the man page for dyld on this machine
$ export DYLD_PRINT_RPATHS=1 $ clang hello.c -o hellodyld: warning, unknown environment variable: DYLD_PRINT_RPATHS dyld: warning, unknown environment variable: DYLD_PRINT_RPATHS dyld: warning, unknown environment variable: DYLD_PRINT_RPATHS dyld: warning, unknown environment variable: DYLD_PRINT_RPATHS dyld: Library not loaded: @rpath/libLLVM.dylib Referenced from: /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib Reason: image not found clang: error: unable to execute command: Trace/BPT trap clang: error: linker command failed due to signal (use -v to see invocation)
Switching back to clang-3.7 everything works fine. Here's the output from otool for clang-3.7.
$ sudo port select clang mp-clang-3.7
Selecting 'mp-clang-3.7' for 'clang' succeeded. 'mp-clang-3.7' is now active.
$ sudo port select llvm mp-llvm-3.7
Selecting 'mp-llvm-3.7' for 'llvm' succeeded. 'mp-llvm-3.7' is now active.
$ clang hello.c -o hello
$ otool -l /opt/local/libexec/llvm-3.7/bin/../lib/libLTO.dylib | grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 40
path @executable_path/../lib (offset 12)
and finally, of course setting the library fallback path manually works (switched to clang-3.9)
$ export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/libexec/llvm-3.9/lib/ $ clang -v hello.c -o hello clang version 3.9.0 (trunk 270400) Target: x86_64-apple-darwin10.8.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-3.9/bin "/opt/local/libexec/llvm-3.9/bin/clang" -cc1 -triple x86_64-apple-macosx10.6.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -main-file-name hello.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 136 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0 -fdebug-compilation-dir /Users/Shared/test_llvm -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.6.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/hello-49b326.o -x c hello.c clang -cc1 version 3.9.0 based upon LLVM 3.9.0svn default target x86_64-apple-darwin10.8.0 #include "..." search starts here: #include <...> search starts here: /usr/local/include /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/opt/local/libexec/llvm-3.9/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o hello -lcrt1.10.6.o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/hello-49b326.o -lSystem /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0/lib/darwin/libclang_rt.osx.a $ ./hello hello world
just odd I didn't have to do that manual lib path setting for clang-3.7
hope this is helpful to someone
comment:6 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
DYLD_PRINT_RPATHS was added in Lion. One release off! ><
I wonder if something's up with SnowLeopard's dyld getting confused by our symlinks.
Does it work correctly if you execute /opt/local/bin/clang-mp-3.8 ?
Does it work correctly if you execute /opt/local/libexec/llvm-3.8/bin/clang ?
comment:7 Changed 8 years ago by kenneth.f.cunningham@…
unfortunately neither of those options worked. But at least I can use the fallback library setting workaround on this machine. I love this old MacbookPro 2,1 -- but it's stuck at 10.6.8/10.7 for hardware reasons, hence the snowleopard fetish.
If you have any more ideas / want me to explore something further just ask.
comment:8 follow-up: 17 Changed 8 years ago by kenneth.f.cunningham@…
Oh, wait a sec -- this seems to have fixed it for clang-3.9
sudo install_name_tool -add_rpath /opt/local/libexec/llvm-3.9/lib /opt/local/libexec/llvm-3.9/bin/../lib/libLTO.dylib
and this one fixes clang-3.8
sudo install_name_tool -add_rpath /opt/local/libexec/llvm-3.8/lib /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib
do you think this might need to be done for all the dozens of libraries in the llvm-3.8/lib and llvm-3.9/lib folders?
comment:9 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
That is what @loader_path should be evaluating to...
comment:10 Changed 8 years ago by kenneth.f.cunningham@…
OK - here's a few more clues.
clang-3.4, which works out of the box, has this otool output:
$ otool -l /opt/local/libexec/llvm-3.4/bin/../lib/libLTO.dylib | grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 40
path @executable_path/../lib (offset 12)
clang-3.7, which also works out of the box, has this otool output:
$ otool -l /opt/local/libexec/llvm-3.7/bin/../lib/libLTO.dylib | grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 40
path @executable_path/../lib (offset 12)
clang-3.8, which did not work without modification, has this (the last entry I added with the install_name_tool:
KensMacBookPro:test_llvm cunningh$ otool -l /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib | grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 32
path @loader_path (offset 12)
--
cmd LC_RPATH
cmdsize 40
path @executable_path/../lib (offset 12)
--
cmd LC_RPATH
cmdsize 48
path /opt/local/libexec/llvm-3.8/lib (offset 12)
and clang-3.9, which also did not work without modification, has this:
$ otool -l /opt/local/libexec/llvm-3.9/bin/../lib/libLTO.dylib | grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 32
path @loader_path (offset 12)
--
cmd LC_RPATH
cmdsize 40
path @executable_path/../lib (offset 12)
--
cmd LC_RPATH
cmdsize 48
path /opt/local/libexec/llvm-3.9/lib (offset 12)
so - strangely - the two older clang versions, with no @loader_path set, work. The newer two, with the @loader_path, do not (unless I hard code it in).
I've been reading this article over <https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath> and I don't see the reason this is happening, but perhaps you do.
comment:11 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
3.3 through 3.7 used the full path as the dylib identifier instead of @rpath. With 3.8, we went to using @rpath as that is what upstream prefers we do. That's why you wouldn't see any issue with earlier versions.
comment:12 Changed 8 years ago by kenneth.f.cunningham@…
OK, I get it now. Perhaps it's something about this specific machine then. I don't know what 3rd party software would interfere with @loader_path -- I have Parallels installed. Some other stuff, the usual mix that accumulates over time. Nothing else down in the innards.
I have another machine that can run SnowLeopard - a MacPro 5,1 - I'll install clang-3.8 on that, and see if that does the same thing.
comment:13 Changed 8 years ago by kenneth.f.cunningham@…
Well - installed fresh macports on a different machine running snowleopard and then installed only clang-3.8 -- downloaded it precompiled - but seems to be showing the same problem.
$ which clang
/opt/local/bin/clang
$ clang --version
clang version 3.8.0 (branches/release_38 262722)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-3.8/bin
$ clang hello.c -o hello
dyld: Library not loaded: @rpath/libLLVM.dylib
Referenced from: /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib
Reason: image not found
clang: error: unable to execute command: Trace/BPT trap
clang: error: linker command failed due to signal (use -v to see invocation)
$ otool -L /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib
/opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib:
@rpath/libLTO.dylib (compatibility version 1.0.0, current version 3.8.0)
@rpath/libLLVM.dylib (compatibility version 1.0.0, current version 3.8.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 3.7.1)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 3.7.0)
$ otool -l /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib | grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 32
path @loader_path (offset 12)
--
cmd LC_RPATH
cmdsize 40
path @executable_path/../lib (offset 12)
comment:14 Changed 8 years ago by kenneth.f.cunningham@…
and just installed a fresh copy of clang-3.8 on the same machine running 10.11.5 -- and it works perfectly without modification, and with what would appear to be the exact same output from otool . So it would seem to be a SnowLeopard thing, I guess.
$ clang hello.c -o hello
$ ls
hello hello.c
$ ./hello
hello world
$ otool -L /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib
/opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib:
@rpath/libLTO.dylib (compatibility version 1.0.0, current version 3.8.0)
@rpath/libLLVM.dylib (compatibility version 1.0.0, current version 3.8.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
$ otool -l /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib | grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 32
path @loader_path (offset 12)
--
cmd LC_RPATH
cmdsize 40
path @executable_path/../lib (offset 12)
comment:15 Changed 8 years ago by kenneth.f.cunningham@…
Jeremy -- adding @loader_path/ to the rpaths seems to fix the issue with snowleopard.
sudo install_name_tool -add_rpath @loader_path/ /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib
$ otool -l /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylib | grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 32
path @loader_path (offset 12)
--
cmd LC_RPATH
cmdsize 40
path @executable_path/../lib (offset 12)
--
cmd LC_RPATH
cmdsize 32
path @loader_path/ (offset 12)
$ clang -v hello.c -o hello clang version 3.8.0 (branches/release_38 262722) Target: x86_64-apple-darwin10.8.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-3.8/bin "/opt/local/libexec/llvm-3.8/bin/clang" -cc1 -triple x86_64-apple-macosx10.6.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name hello.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 136 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.0 -fdebug-compilation-dir /Users/Shared/test_llvm -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.6.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/hello-d43f94.o -x c hello.c clang -cc1 version 3.8.0 based upon LLVM 3.8.0 default target x86_64-apple-darwin10.8.0 #include "..." search starts here: #include <...> search starts here: /usr/local/include /opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.0/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/opt/local/libexec/llvm-3.8/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o hello -lcrt1.10.6.o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/hello-d43f94.o -lSystem $ ./hello hello world
comment:16 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Thanks. That's good info and should lead to a usable workaround for the Portfile.
comment:17 Changed 8 years ago by noloader (Jeffrey Walton)
Replying to kenneth.f.cunningham@…:
Oh, wait a sec -- this seems to have fixed it for clang-3.9
sudo install_name_tool -add_rpath /opt/local/libexec/llvm-3.9/lib /opt/local/libexec/llvm-3.9/bin/../lib/libLTO.dyliband this one fixes clang-3.8
sudo install_name_tool -add_rpath /opt/local/libexec/llvm-3.8/lib /opt/local/libexec/llvm-3.8/bin/../lib/libLTO.dylibdo you think this might need to be done for all the dozens of libraries in the llvm-3.8/lib and llvm-3.9/lib folders?
Sorry to dig up an old report... Here's another data point.
MBP 2012, OS X 10.8.5, fully patched (or as patched as it can be)... Running install_name_tool cleared the issue for me with clang++-mp-3.9.
It also cleared a problem when using GCC 6.1 with -Wa,-q. Here's what that issue looked like (I'm not filing a bug report on it):
/opt/local/bin/gcc-mp-6 -o cryptest.exe -DNDEBUG -g2 -O2 -fPIC -march=native -Wa,-q -pipe
bench1.o bench2.o test.o validat1.o validat2.o validat3.o adhoc.o datatest.o regtest.o
fipsalgt.o dlltest.o ./libcryptopp.a
Undefined symbols for architecture x86_64:
"std::ctype<char>::_M_widen_init() const", referenced from:
BenchmarkAll(double, double) in bench1.o
PrintSeedAndThreads(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&) in test.o
BlockTransformationTest(CipherFactory const&,
CryptoPP::BufferedTransformation&, unsigned int) in validat1.o
ValidateRC2() in validat1.o
ValidateBBS() in validat2.o
ValidateECP() in validat2.o
HashModuleTest(CryptoPP::HashTransformation&, HashTestTuple
const*, unsigned int) in validat3.o
...
"std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::find(char const*, unsigned long, unsigned
long) const", referenced from:
_main in test.o
...
However, we still get the endless stream of assembler warnings detailed at http://stackoverflow.com/q/38193043. The warnings are only present with GCC using Clang Integrated Assembler (I'm not filing a bug report on it).
comment:18 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Your C++ link failures with gcc6 have nothing to do with this particular issue. I strongly suggest you use clang++ and libc++ for your C++ needs, but if you really want to use gcc, make sure you use g++ to link your C++ code.
comment:19 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
here's the verbose output