clang parser: can libclang be loaded dynamically?

Milian Wolff mail at
Tue Apr 12 00:38:05 UTC 2016

On Montag, 11. April 2016 11:30:53 EDT René J.V. Bertin wrote:
> Hi,
> This came up in a discussion on a MacPorts forum, concerning packaging
> dependencies on a clang/llvm version.
> If I understood an earlier exchange about libclang correctly, it is the only
> dependency on the LLVM toolchain, and that library provides an API that
> hasn't changed since clang 3.5 (or hardly so). If so, that suggests it
> might be possible to build the clang-based parser against one version, and
> load (dlopen) a the library dynamically (using a configurable location),
> more or less like how audacity uses the ffmpeg libraries. I haven't looked
> at how much work this would represent, I'd first like to know if it's
> indeed theoretically possible, and not "just theoretically" (i.e. it's
> feasible or even relatively trivial).
> The advantage for packagers would of course be that a KDevelop package
> doesn't need a hard dependency on a given clang+llvm version, or ship its
> own libclang. On OS X it might even allow to use the libclang included with
> Xcode, which cannot be used otherwise (the toolchain misses items required
> to build against it) and which will probably give better performance as
> Apple's clang has always out-performed local builds.

I don't get it. You link against and be done with it. If the ABI 
changes, you get a runtime link error. If the ABI is stable, and a fitting lib 
can be found everything works. Why do you need to dlopen? The dynamic linker 
can handle that for us just fine.

Milian Wolff
mail at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the KDevelop-devel mailing list