clang parser: can libclang be loaded dynamically?

[Kevin Funk]

On Monday, April 11, 2016 11:30:53 AM CEST 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).

Yes, *ABI changes* in libclang are not allowed. That's one of the (main) 
reasons it's there, to begin with.

> 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. 

You can do, but note you can only load a library with the same/higher version, 
otherwise you might run into unresolved symbols when loading library on 
startup. (I'm sure you know that, yes.)

> 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).

Yes.

> 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.

I still don't get what's so hard to just provide a standalone, reusable LLVM + 
Clang package on MacPorts, though...

It took me 10 minutes to set that up on Windows using Emerge, something which 
now works globally across all Windows versions.

(Time to revisit policies/workflows in the MacPorts project...?)

> 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.

Ask on the resp. mailing lists (cfe-dev) and check what's wrong with your 
local build. I can't help with that. You definitely should get comparable 
performance out of your local build.

Cheers,
Kevin

> Thanks,
> René
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kdevelop-devel


-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- 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: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160411/2feb488a/attachment.sig>