#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: new Component: ports | Milestone: Resolution: | Version: 2.3.4 Port: llvm-3.8, clang-3.8, ld-latest | Keywords: ---------------------------------------------+----------------------------- Comment (by jeremyhu@…): ld64 needs to set its rpath. Working on this now. -- Ticket URL: <https://trac.macports.org/ticket/50853#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X

#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@…): Why not simply set the correct id in libLTO, libLLVM and libclang since they're not being installed in a standard location? I don't really see the point in forcing any user of those libraries (or simply libclang) to be obliged to figure out and add their location to the rpath ... -- Ticket URL: <https://trac.macports.org/ticket/50853#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X

#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@…): In that case upstream should take the necessary steps to ensure that the appropriate rpath is added via llvm-config, the cmake scripts and whatever else. -- Ticket URL: <https://trac.macports.org/ticket/50853#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X

#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@…): Yeah, sure. It'd just be a bit strange for me to argue that this should be done in (large) part for the sake of distribution/packaging systems like MacPorts; that argument probably stands to lose a lot of weight if not made by the maintainer of the clang port/package of such a distribution system. Esp. since it's almost trivial to work around the whole issue using a few `install_name_tool` invocations in the post-destroot. I'm taking this up with the main dev of KDevelop's Clang-based parser. -- Ticket URL: <https://trac.macports.org/ticket/50853#comment:7> MacPorts <https://www.macports.org/> Ports system for OS X

#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

#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 noloader@…): Please forgive my ignorance. What is the fix? What should I do to avoid the link problems I am experiencing? Comment 8 (https://trac.macports.org/ticket/50853#comment:8) seems to have the most promise, but it lacks details. That is, we are not told the exact command to execute to fix the problem. My apologies for asking. I was referred to this bug from another one. -- Ticket URL: <https://trac.macports.org/ticket/50853#comment:11> MacPorts <https://www.macports.org/> Ports system for OS X