Displaying 20 results from an estimated 5000 matches similar to: "Statically linking against libc++"
2016 Sep 30
4
(Thin)LTO llvm build
I just built a stage-1 compiler from the 3.9 release bits and built the
lldb from head sources which worked fine. Let me try again using 3.9 build
compiler to build 3.9 bits. Teresa
On Tue, Sep 27, 2016 at 2:55 PM, Teresa Johnson <tejohnson at google.com>
wrote:
>
>
> On Tue, Sep 27, 2016, 2:38 PM Carsten Mattner <carstenmattner at gmail.com>
> wrote:
>
>> On
2016 Jan 14
2
Building SVN head with CMake - shared libraries?
Now that autoconf is going away soon, I figured I'd try building using
CMake.
I checked out llvm, cfe and lldb from the SVN server, and followed the
basic build instructions.
cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=/tools/llvm/svn_head
-DLLVM_TARGETS_TO_BUILD="X86;CppBackend" -DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_ASSERTIONS=ON ../llvm
Everything worked well, and in
2016 Jan 14
4
Building SVN head with CMake - shared libraries?
Thanks - I'll try this tonight.
Assuming it works, should these variables be added to the docs at
http://llvm.org/docs/CMake.html ?
On Wed, Jan 13, 2016 at 10:26 PM, Andrew Wilkins <axwalk at gmail.com> wrote:
>
>
> On Thu, 14 Jan 2016 at 11:02 David Jones via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Now that autoconf is going away soon, I
2016 Sep 27
2
(Thin)LTO llvm build
On Tue, Sep 27, 2016 at 11:17 PM, Teresa Johnson <tejohnson at google.com> wrote:
> Sure, I will try this and let you know. Unfortunately, though, I
> have another big work commitment that is going to eat up most of my
> time through Thu, although I may be able to find some time to try
> it.
No worries, if I get around it before you do, I will :).
> I think so - what is
2017 Apr 10
2
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?
2012 Oct 25
1
[LLVMdev] How to include IR parser and optimization passes in my project
Hi,
I am a newbie in LLVM.
I am very impressed with this forum and appreciate your help and time.
I am trying to include llvm IR parser in my codebase, the way I wanna
do is generate llvm's shared object (.so) file and use it in my
project.
So far I haven't been able to generate correct .so's.
When I build a debug build with gmake (have llvm and clang in my
sandbox), I get the
2016 Sep 27
2
(Thin)LTO llvm build
On Tue, Sep 27, 2016 at 8:37 PM, Teresa Johnson <tejohnson at google.com> wrote:
Just in case it's important, I'm using Arch Linux (and most Linux
distros these days) CFLAGS/CPPFLAGS/LDFLAGS, which are as follows:
$ grep FLAGS /etc/makepkg.conf
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
2019 Mar 25
3
Trying to create a pure LLVM toolchain on musl based distribution
Hello,
I'm trying to create a pure LLVM toolchain (that will not depend on GNU
and produce GNU-free code too) on a musl based distribution.
For now, I use gcc to bootstrap and build all LLVM components. I do it
individually because I was running out of space and memory trying to
build all using LLVM_ENABLE_PROJECTS. Also, I don't want to create a
all-in-one package. Then, once
2017 Apr 10
2
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
2018 Mar 05
2
[Release-testers] [6.0.0 Release] The final tag is in
It was just brought to my attention that the RPATH configuration isn't
uniform among the libraries produced by the release. Some use
$ORIGIN../lib/ and others have none. Is this by design? It seems like it
might be ideal for all of them to be configured the same way. If that
makes sense I'll create a corresponding feature request.
$ for f in
2018 Mar 05
2
[Release-testers] [6.0.0 Release] The final tag is in
Isn't libc++.so dependent on libc++abi.so?
On Mon, Mar 5, 2018 at 10:30 AM, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote:
> From what I can see all of the libraries without RPATH are runtime
> libraries that are used by binaries compiled with Clang. I think they don't
> have a dependency on other libraries in that directory, so what would be
> the advantage of having
2018 Mar 05
0
[Release-testers] [6.0.0 Release] The final tag is in
From what I can see all of the libraries without RPATH are runtime
libraries that are used by binaries compiled with Clang. I think they
don't have a dependency on other libraries in that directory, so what
would be the advantage of having RPATH set on them?
Regards,
Jonas
Am 2018-03-05 17:23, schrieb Brian Cain via llvm-dev:
> It was just brought to my attention that the RPATH
2018 Mar 05
0
[Release-testers] [6.0.0 Release] The final tag is in
libc++.so should be a linker script that automatically pulls in
libc++abi (see "Failed to read file header" in your output). And IIRC
libc++abi is only one possible implementation that may be used by
libc++, but I'm no expert here...
Am 2018-03-05 17:33, schrieb Brian Cain:
> Isn't libc++.so dependent on libc++abi.so?
>
> On Mon, Mar 5, 2018 at 10:30 AM, Jonas
2018 Feb 26
0
Linking libc++(abi) (ideally statically) on non-llvm OS
I've been unsuccessfully trying tell g++ or clang++ to use libc++(abi)
when building a C++ source file (single file for test purposes) when
the host cc and c++ are all configured to use glibc and libstdc++.
My goal is to statically links musl libc and libc++(abi) and create
binaries for Linux that just work anywhere. Naturally, I'm not
building a .so or depending on dynamic libs.
My last
2017 Jun 06
3
libc++ failed to link against musl
On 5 Jun 2017, at 15:17, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> On 6/5/17 5:17 AM, Dmitry Golovin via llvm-dev wrote:
>> I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain.
>>
>> The configuration is the following:
>>
>> LIBCXX_HAS_MUSL_LIBC=ON
>>
2019 Aug 03
3
conflicting builtins in clang with musl (stddef.h)
Hello there,
I'm building a Linux distribution based on musl and LLVM as default
toolchain (including lld/libc++/libc++abi/libunwind rather than GNU).
For most of the time this works pretty well.
However I'm having troubles with few packages, webkit for instance
fails because of max_align_t being redeclared in musl's stddef.h
I see that stddef.h is provided by both musl and in the
2019 Apr 12
2
Failed to replace stdlibc++ with libc++, linker phase error
Hi,
I'm currently working on one of my team's project to build LLVM full clang
toolchain (Clang, libcxx, libcxxabi) on a CentOS machine.
Previously we compiled our codebase with llvm-toolset-7/clang++, which by
default takes stdlibc++ to compile and link. And now we'd like to switch to
use LLVM clang with libc++. I have built libc++ and libc++abi from source
(5.0.1 release) and set
2018 Mar 04
0
[Release-testers] [6.0.0 Release] The final tag is in
Uploaded ubuntu, SLES11, SLES12 binaries.
4907dbd37f4e5265a2f1252d9d7b5e5b0a9c0ec1
clang+llvm-6.0.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz
360b26fcd9eafe5ca9c4baa89c38339bc587c094
clang+llvm-6.0.0-x86_64-linux-sles11.3.tar.xz
ce525cf949ef86409bc3f4f492035225989eecfd
clang+llvm-6.0.0-x86_64-linux-sles12.2.tar.xz
On Fri, Mar 2, 2018 at 6:17 AM, Hans Wennborg via Release-testers <
release-testers
2017 Jun 05
3
libc++ failed to link against musl
I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain.
The configuration is the following:
LIBCXX_HAS_MUSL_LIBC=ON
LIBCXX_HAS_GCC_S_LIB=OFF
CLANG_DEFAULT_CXX_STDLIB=libc++
CLANG_DEFAULT_LINKER=lld
CLANG_DEFAULT_RTLIB=compiler-rt
LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl
LLVM_TARGET_ARCH=x86_64
2017 Jun 07
2
libc++ failed to link against musl
On 6 Jun 2017, at 21:41, Dmitry Golovin <dima at golovin.in> wrote:
>
> Neither is the case. The system that I want to build with this toolchain is Linux-based, but not GNUish. I would like to use musl instead of glibc and libc++ instead of libstdc++, only use binutils provided by LLVM. I think that in that case I will link libc++abi and libunwind to libc++ statically, so I will not