On středa 24. ledna 2018 1:47:47 CET Aaron Puchert wrote:
Hi,
I like the idea, it seems like the right way to go. If it works for Fedora, it's probably good enough.
Hi, Thank you for the feedback!
* The package clang-devel contains headers for both C API (in /usr/include/clang-c) and C++ API (in /usr/include/clang), but libclang.so from the same package only exposes symbols for the former. * Using the C++ API, I have to install clang-devel-static, which is a gigantic package, and linking against it is quite slow.
Luckily this problem will go away with the new changes because we'll get rid of the clang-devel-static package and have again only clang-devel.
* Unlike libclang.so, libLLVM.so exposes both C and C++ API, which seems inconsistent. So using both with the C++ API I link statically with one and dynamically with another?
Yeah, in the current setup that is the way to do it. And it can cause bugs like the bnc#1065464 if you get mixed with another library that also linked statically to clang.
So technically Clang supports the single dynamic library (3), but that library only exposes the C API.
As I understand it, the libclang.so is different than libLLVM.so. As you observed, it exposes only the stable C API and so it is linked (statically or dynamically) only to *some* of the clang components. So the remaining components still have to be distributed. If you build LLVM as a single dynamic library, the libLLVM.so contains and exposes all the available LLVM components. I do not know of a way to build libclang.so in such way.
Which makes me think that the advice against using BUILD_SHARED_LIBS only applies to LLVM and not Clang, since otherwise there would be no shared library build exposing Clang's C++ API. That advice is also from the LLVM documentation, and I couldn't find anything similar for Clang.
Hopefully that is true. Michal -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org