[llvm-dev] Statically linking against libc++

[Mehdi Amini via llvm-dev]

> On Apr 10, 2017, at 6:49 AM, Carsten Mattner <carstenmattner at gmail.com> wrote:
> 
> On Mon, Apr 10, 2017 at 8:42 AM, C Bergström <cbergstrom at pathscale.com> wrote:
>> -DBUILD_SHARED_LIBS=OFF should be exactly that, but as I think
>> someone else indicated there's a bit of work for it to actually be
>> what it advertises to be.
> 
> Mehdi wrote it's correct for all of the listed dynlibs to be
> installed.

I can be wrong as well :)

But here that’s not my reading of the documentation: http://llvm.org/docs/CMake.html <http://llvm.org/docs/CMake.html>

BUILD_SHARED_LIBS:BOOL
Flag indicating if each LLVM component (e.g. Support) is built as a shared library (ON) or as a static library (OFF). Its default value is OFF. On Windows, shared libraries may be used when building with MinGW, including mingw-w64, but not when building with the Microsoft toolchain.



This applies to the individual LLVM component. I don’t think the shared lib you mentioned are part of this.


> 
>> This could get gray when you consider that you really need to decide
>> - did you mean compiler internal libs or runtime stuff. libomp.so vs
>> libLLVM.so is two entirely different use cases.
> 
> Yep, I'm talking about zero LLVM libs needed at runtime after linking,
> unlike say libstdc++ and libgcc needed in your typical Linux
> executable.

When I build clang, I always get libc++.so and libc++.a ; I don’t think there is an option to have clang always link libc++ statically afterward though. I believe it requires to opt-in explicitly when you link with clang.

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170410/05fa4dfe/attachment.html>