[cfe-dev] libclang shared library that exports all symbols

[Pirama Arumuga Nainar via cfe-dev]

On Fri, Aug 3, 2018 at 1:37 AM Ivan Donchevskii <ivan.donchevskii at qt.io>
wrote:

> Hi!
> 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
> flags.
>

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

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,
>
> Ivan
> ------------------------------
> *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>
> wrote:
>
> 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.
>
> Motivation:
> 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?
>
> [1]
> https://android.googlesource.com/platform/development/+/master/vndk/tools/header-checker/
> [2]
> https://android.googlesource.com/platform/development/+/master/vndk/tools/vtable-dumper/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180806/c853a9bf/attachment.html>