rpath support for libclang and its dependents

René J.V. Bertin rjvbertin at gmail.com
Sun Mar 13 18:25:18 UTC 2016


Hi,

I already posted this off-list but apparently the tidbit got overlooked:

On OS X, llvm builds libLTO, libLLVM and libclang with the internal id set to @rpath/libLTO.dylib (etc). Even if you use the static libLLVM that means that libclang will be expected at the path @rpath/libclang.dylib, IOW dependent applications need to have libclang's location added to their rpath if that location isn't one searched by default by the dynamic loader. I've been told "that's how upstream want it" (upstream = llvm.org). 
Apparently llvm-config and/or the llvm/clang cmake scripts do not provide the proper linker flags for that, because I've already seen several applications fail because of a "missing" @rpath/libclang.dylib .

Are you aware of this, and do you also think that it's not up to dependent applications to figure out if and how the rpath should be modified to use libclang and/or libLLVM (in addition to using `llvm-config --ldflags`)? If you do someone ought to file a request, and it'd probably carry more weight when done by a member of a well-known project that builds on libclang, rather than an individual user who could just as well run install_name_tool on the libraries in question to correct their id ;)

Which btw. is exactly what MacPorts (where I get my llvm+clang builds from) has been doing up to llvm 3.8 (which is why I thought initially that using @rpath was a new policy in 3.8).

R.


More information about the KDevelop-devel mailing list