Carsten Mattner via llvm-dev
2017-Apr-10 07:55 UTC
[llvm-dev] Statically linking against libc++
On Mon, Apr 10, 2017 at 4:59 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:> Note that -DBUILD_SHARED_LIBS=OFF is not a special settings, > this is the default.Is there a so=NEVER setting?
C Bergström via llvm-dev
2017-Apr-10 08:42 UTC
[llvm-dev] Statically linking against libc++
-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. 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. 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. 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 # To avoid confusion - that link depends only on open source stuff On Mon, Apr 10, 2017 at 3:55 PM, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On Mon, Apr 10, 2017 at 4:59 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> Note that -DBUILD_SHARED_LIBS=OFF is not a special settings, >> this is the default. > > Is there a so=NEVER setting? > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Carsten Mattner via llvm-dev
2017-Apr-10 13:49 UTC
[llvm-dev] 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-suiteDo you mind going into the differences of me running cmake _many_opts_ && ninja install?
Possibly Parallel Threads
- Statically linking against libc++
- Statically linking against libc++
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers