[cfe-dev] libclang shared library that exports all symbols
Pirama Arumuga Nainar via cfe-dev
cfe-dev at lists.llvm.org
Mon Aug 6 13:53:29 PDT 2018
On Fri, Aug 3, 2018 at 1:37 AM Ivan Donchevskii <ivan.donchevskii at qt.io>
> Why do you need to mix C++ symbols with what libclang exports?
My reasoning was that the C/C++ difference was already imposed by the
headers included by a libclang.so user. But I also see why limiting the
exported symbols can catch user errors.
> Doesn't it make sense to have separate clang.so instead? I also think
> there's already a possibility to build such library by providing some LLVM
I think you mean LLVM_ENABLE_SHARED? That builds each individual library
(libclangAST, libclangDriver etc) as shared libraries, rather than
producing a single shared library. I am not aware of any other option that
To clarify my proposal, I've uploaded a patch (
https://reviews.llvm.org/D50359) that adds this new library. The library
is named libclang-cxx in that patch - which I think is slightly more
informative than libclang-full.
Please add comments in the patch or to this discussions.
> Kind regards,
> *From:* cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Pirama
> Arumuga Nainar via cfe-dev <cfe-dev at lists.llvm.org>
> *Sent:* Thursday, August 2, 2018 11:48:16 PM
> *To:* cfe-dev list
> *Cc:* Tzu-hsiang Chien
> *Subject:* Re: [cfe-dev] libclang shared library that exports all symbols
> Ping for any thoughts on this proposal...
> On Thu, Jul 26, 2018 at 3:59 PM Pirama Arumuga Nainar <pirama at google.com>
> libclang.so exports only the symbols needed by the C API. This is in
> contrast to libLLVM.so that exports all symbols from the LLVM static
> libraries. Would it be useful to provide a libclang shared library that
> exports all symbols for use by tools that use Clang's (admittedly
> non-backwards-compatible) C++ API?
> We can either:
> 1. Add a new shared library (libclang_full.so?) that is built based on a
> CMake option.
> 2. Export all symbols from the current libclang.so. We'd have to also
> include a few additional libraries such as libClangAnalysis. Tools using
> the C API are still restricted to the stable interface if they use the
> clang-c headers.
> There are a few Clang-based tools used by Android's build system (1, 2)
> that use the C++ API. They are built using Android build rules but need to
> link against Android's Clang toolchain that's built with CMake. We don't
> want to include the libclang static libraries with the toolchain for space
> considerations, and also to avoid exposing Clang's build internals
> (internal library dependences and changes to them) to downstream tools.
> Do other Clang/LLVM toolchain maintainers face similar issues and have
> solutions that are applicable here?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev