[MacPorts] #50853: "dyld: Library not loaded: @rpath/libLLVM.dylib" in clang-3.8 and ld64-latest +llvm38

[MacPorts]

#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