llvm dev - Apr 2017 - Statically linking against libc++

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.
> 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.
> Did you want to disable ever being able to use a shared lib or just
> build a static version of the compiler so that it's portable.
Building a static compiler wasn't on my agenda, but since it takes a
long time to build it all, I would love such a target for sharing it
between all Linux distros.
> Shameless self promotion, but this does the latter while preserving
> the former.. Nice clean wrapper around everything that makes a
> compiler that is portable and has all the pieces you need bundled
> together.. https://github.com/pathscale/clang-suite
Do you mind going into the differences of me running
cmake _many_opts_ && ninja install?

> 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>

On Mon, Apr 10, 2017 at 3:57 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> I can be wrong as well :)
>
> But here that’s not my reading of the documentation:
> 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.
I set this in the cmake invocation for all of llvm from the root.
Do I need to do this differently for it to affect every project?
> 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.
Yeah you need -static globally in the CXX call which may not be
flexible enough, but you could argue that if one needs to link
libc++ statically they should run it where everything is used
is available for -static use.