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

Pirama Arumuga Nainar via cfe-dev cfe-dev at lists.llvm.org
Wed Sep 12 10:57:19 PDT 2018


Hi Ivan,

Thanks for pointing out Clang plugins as a viable alternative for my
proposal.  We had considered writing the tools as a plugin but decided
against it - due to some rough edges with Android's build system.

For now, we decided to carry build rules for the proposed library in
downstream.  I've updated my change (https://reviews.llvm.org/D50359) to
make it more general, and will leave it open in case there's more interest
to revive it in the future.

Thanks,
-Pirama

On Mon, Aug 6, 2018 at 11:28 PM Ivan Donchevskii <ivan.donchevskii at qt.io>
wrote:

> Hi!
>
> I think I meant CLANG_PLUGIN_SUPPORT flag which enables
> export_executable_symbols(clang) in
> tools\clang\tools\driver\CMakeLists.txt
>
> Probably in combination with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS.
>
>
> Ivan
> ------------------------------
> *From:* Pirama Arumuga Nainar <pirama at google.com>
> *Sent:* Monday, August 6, 2018 10:53:29 PM
> *To:* Ivan Donchevskii; cfe-dev list
> *Cc:* Tzu-hsiang Chien; Stephen Hines
> *Subject:* Re: [cfe-dev] libclang shared library that exports all symbols
>
>
>
> 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/20180912/6ca51660/attachment.html>


More information about the cfe-dev mailing list