#50853: "dyld: Library not loaded: @rpath/libLLVM.dylib" in clang-3.8 and ld64-latest +llvm38 ---------------------------------------------+----------------------------- Reporter: rjvbertin@… | Owner: macports- Type: defect | tickets@… Priority: Normal | Status: closed Component: ports | Milestone: Resolution: fixed | Version: 2.3.4 Port: llvm-3.8, clang-3.8, ld-latest | Keywords: ---------------------------------------------+----------------------------- Comment (by rjvbertin@…): Replying to [comment:2 jeremyhu@…]:
r146522
Seems you missed something: {{{
otool -L /opt/local/libexec/ld64/ld-latest /opt/local/libexec/ld64/ld-latest: @executable_path/../lib/libLTO.dylib (compatibility version 1.0.0, current version 3.8.0) /usr/lib/libxar.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) }}}
I'd suggest advocating for a pkg-config file for libllvm and libclang rather than updating the llvm-config scripts.
Ideally dependent build systems would have to change as little as possible. But apparently this is not something new, which kind of begs the question why we're applications like ld64 didn't already have the proper addition to their rpath. With llvm designed to support multiple versions installed in parallel it shouldn't be that uncommon to have libraries with a version number in the name (libLTO, libclang) someplace *not* in the dynamic loader's standard search path, right? -- Ticket URL: <https://trac.macports.org/ticket/50853#comment:9> MacPorts <https://www.macports.org/> Ports system for OS X