similar to: [LLVMdev] Dynamic linking (dlopen/dlsym) against LLVM from a C program

Try as I might I can't seem to get LLVM to bulid using clang/clang++. No matter what I do it insists on using /usr/bin/cc and /usr/bin/c++ which are gcc. Am I missing something obvious? I vaguely remember some document describing a stage1 compiler built by your old toolchain and a stage2 compiler but I can't find the steps to do that any more. $ CC=/usr/local/bin/clang

On Thu, Sep 3, 2015 at 6:45 PM, Kostya Serebryany <kcc at google.com> wrote: > Did you build the Postgres code with -fsanitize-coverage=... ? Yes: CC = clang CFLAGS = -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -g -O0 -fsanitize=address

Hi Jack, Are you packaging all the static libraries that lld produces as part of the package ? PS : When I build on x86_64, I only get a 9M image for lld. Thanks Shankar Easwaran On 11/20/2013 9:15 AM, Jack Howarth wrote: > When lld-3.4 is added to the tools directory of the llvm source tree > as lld, the resulting cmake build produces a huge number of static libs and > bloats

I'm developing an llvm-based compiler and when I try to generate executable file the following error occurs: ./bin/llvmcode.s:35: undefined reference to `operator new[](unsigned long)' Note that in the generated IR, the function '@_Znam' is called which is located in one of llvm libraries. So, I should have linked the generated assembly file with that library. Here is the code I

Hello, I update my building scripts to build LLVM 4.0 RC1 (with clang, lldb, libc++, libc++abi, lld) on CentOS 6 and I got a lot of undefined symbols during linking LLDB. I'm using clang-3.9 and this configuration: -DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++

On Thu, Sep 3, 2015 at 6:25 PM, Kostya Serebryany <kcc at google.com> wrote: > Not sure I understood this correctly. > Example? I've made a Postgres module which is dynamically loaded by Postgres as a shared library from which I can call the fuzzer on the SQL function of my choice. Postgres has enough meta information about the functions that I think the eventual interface might

Hi Nate. I've noticed that when I hardcode ExecutionEngine::areDlsymStubsEnabled() to always return false, check-lit still passes. I'm working on fixing a couple bugs in the JIT that involve changing how stubs are handled. I'm being careful around dlsym stubs, but I'm not perfect and may make a mistake. I'd really appreciate if you could add some tests for the code you added

When testing which “dl library” we must use for dl* symbols, autoconf runs a test similar to: $ cat conftest.c char dlopen (); int main () { return dlopen (); } $ gcc -o conftest $CFLAGS conftest.c [try various -ldl options here] When using ‘CFLAGS="-fsanitize=address"’ this succeeds even if no dl libraries are used at all, since it appears that using this option causes dlopen

When lld-3.4 is added to the tools directory of the llvm source tree as lld, the resulting cmake build produces a huge number of static libs and bloats the overall package from... -rw-r--r-- 1 root wheel 86361440 Nov 19 21:09 llvm34_3.4-0_darwin-x86_64.deb to -rw-r--r-- 1 root wheel 495257452 Nov 19 20:49 llvm34_3.4-0_darwin-x86_64.deb Is this a known issue with the initial release of

Looks correct. Can you post the output of libFuzzer here? Something like #0 READ cov: 0 bits: 0 units: 97701 exec/s: 0 #1 pulse cov: 732 bits: 0 units: 97701 exec/s: 0 #2 pulse cov: 737 bits: 0 units: 97701 exec/s: 1 #4 pulse cov: 858 bits: 0 units: 97701 exec/s: 2 #8 pulse cov: 880 bits: 0 units: 97701 exec/s: 4 On Thu, Sep 3, 2015 at 10:50 AM, Greg Stark

Hello, I have just built LLVM with CMake by following these instructions https://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary and I am trying to run the regression tests using "make check-all" but there are some unexpected failures in libcxx and libcxxabi. Here's the test log: Expected Passes : 40745 Expected Failures : 258 Unsupported Tests : 1594

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

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

Included below is a diff between the output from configure on a 64 bit SUse 11.1 (doesn't find libedit) and a 64 bit Suse 10.3 (does find libedit) for otherwise identical setups. 1. How can I get the output set up to look at conftest.c? 2. I added a set -x to configure above LIBEDIT_MSG=no 3. ./configure --with-ldflags="-L/usr/lib64" --with-cflags="-ggdb3

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

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

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

While considering statically linking against libc++ (and other runtime libraries from LLVM), I rebuilt LLVM 4.0 with -DBUILD_SHARED_LIBS=OFF. There are still some .so's in llvm/lib, and only one of them seems to exist exclusively as a DSO (libLTO). There's also livLLVMLTO.a, but I doubt LTO is used after linking a binary so this just looks odd to an uninformed LLVM outside and not

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

Dear testers, The final version of 6.0.0 has just been tagged from the branch after r326550. It has the same contents as -rc3 modulo release notes and one small x86 fix (r326393). Please build the final binaries and upload to the sftp. For those following along: this means llvm-6.0.0 is complete, but it will take a few days to get all the tarballs ready and published on the web page. I will