similar to: [LLVMdev] Building LLVM 2.7 on OpenSolaris

On Jul 29, 2010, at 5:36 PM, Laszlo Kiss wrote: > The build process fails to link the LLVM tools. Specifically, the > first tool to build is 'opt' which results in 700+ undefined symbols. > > I looked into the Makefiles and found that the "LINK_COMPONENTS" make > variable does not get the correct set of libraries. In fact, at the > top level

> I don't know anything about Solaris, but your paste doesn't actually > contain any errors, just warnings (unless I'm reading "ld: warning: > relocation error:" wrong). It might help to run make without -j until > it fails, and then use `make VERBOSE=1` to print the exact commands > it's running. Sorry. There was so much output I wasn't sure how much

What I meant to say was that it worked for me on OS X on a slightly older version of LLVM. Anyway, here's the ld line: "/usr/bin/ld" -export-dynamic -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -shared -o /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib/

Hello everybody, after moving from OS X to Linux build llvm with asan enabled (I also updated to trunk, but not sure if that's related). However, it's totally possible that I missed a step that I took back when I set this up for me, so I might be doing something very stupid. Anyway, I'm configuring LLVM with ../configure --prefix=/home/kfischer/julia/usr --build=x86_64-pc-linux-gnu

Indeed, removing that flag works fine, the only question is why this is added in tools/llvm-shlib/Makefile in the first place then and what to do about it: ifeq ($(HOST_OS), $(filter $(HOST_OS), Linux GNU GNU/kFreeBSD)) # Don't allow unresolved symbols. LLVMLibsOptions += -Wl,--no-undefined endif On Thu, Nov 21, 2013 at 11:53 AM, Alexander Potapenko <glider at

On Thu, Nov 21, 2013 at 6:18 AM, Keno Fischer <kfischer at csail.mit.edu> wrote: > Hello everybody, > > after moving from OS X to Linux build llvm with asan enabled Sorry, I failed to parse this. You're compiling Clang on Linux, and OSX is unrelated, right? > (I also updated > to trunk, but not sure if that's related). However, it's totally possible > that I

This is partly an llvm question, and maybe partly C++. I am trying to make calls on code in the llvm infrastructure.(3.4.2) I appear to be missing some include files, but don't know how to track them down. I get compile errors on existing llvm header files, like the following two examples: -------------------------------------------------------------------------------- In file included

Yeah, it's not linking the runtime because you're building a shared library. This is totally ok. In this case there are undefined __asan_* symbols that are resolved when an instrumented binary loads your library. What's wrong here is that some flag passed to ld prevents it from creating undefined symbols (--no-undefined?). This flag must be removed when building with ASan. This

On Thu, Apr 29, 2010 at 6:31 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Wed, Apr 28, 2010 at 10:48 AM, Yuri <yuri at tsoft.com> wrote: >> Jeffrey Yasskin wrote: >>> >>> We currently use two different techniques to get whole libraries >>> included into the .so. On Linux (gnu ld and gold), we pass >>> --whole-archive, while on

Actually it only link the shlib fine. Linking any executable against it fails: llvm[2]: Linking Release+Asserts executable llvm-lto (without symbols) /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang++ -fsanitize=address -O3 -Wl,-R -Wl,'$ORIGIN/../lib' -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib

On Apr 5, 2011, at 10:53 AM, Tarun Pondicherry wrote: > Hi, > > I'm trying to build llvm on a Solaris/Sparc machine. I get many undefined symbols during the link phase of opt. The link command being run is below. > > It is identical to the link command that gets run and works on an x86 host. > > Thanks, > Tarun > > g++

Jeffrey Yasskin wrote: >> Would you try the patch at >> http://codereview.appspot.com/download/issue968046_1.diff? It should >> make the BSDs fall into the same path as Linux, and since you use gnu >> ld, that should work for you. >> > > Ping? > Sorry for the delay. Here is what I am getting after applying the patch: gmake[2]: Leaving directory

Hi all, (Sorry if the answer to this is obvious - and thanks in advance~) Short version: linker error of _backtrace from LLVMSystem.a building a dynamic library embedding LLVM/clang, both against the OSX 10.4 sdk. Long version: I've just tried rebuilding my project using the 2.6 release, using the following commands to try and force LLVM to build against the OSX 10.4 sdk (I am

On Tue, May 4, 2010 at 5:31 PM, Yuri <yuri at tsoft.com> wrote: > Jeffrey Yasskin wrote: >>> >>> Would you try the patch at >>> http://codereview.appspot.com/download/issue968046_1.diff? It should >>> make the BSDs fall into the same path as Linux, and since you use gnu >>> ld, that should work for you. >>> >> >> Ping?

On Thu, Jul 30, 2009 at 11:03 PM, james northrup<northrup.james at gmail.com> wrote: > CC="p llvm-gcc-4.2 `llvm-config --cflags` -march=i386  --emit-llvm -O0 >  -c -I$PLAT/include -I$ROOT/include -I$ROOT/utils/    include" > LD="p llvm-ld `llvm-config --ldflags --libs all  `" > AR="p llvm-ar crvs" Using llvm-ar+llvm-ld is likely to give you bad

LGTM. I will commit. On Oct 10, 2012, at 1:20 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, > > The attached is the fix to radar://11663049. The optimization can be outlined by following rules: > > (select (x != c), e, c) -> select (x != c), e, x), > (select (x == c), c, e) -> select (x == c), x, e) > where the <c> is an integer

I'm interested in using LLVM for compiling to x86_64 native code (ELF64), so I selected 'x86_64' as the architecture. I added 'host' just-in-case... The '--with-built-clang' selection is for building the Clang LLVM C compiler instead of using a gcc front end. I placed the Clang distribution in './tools/clang'. On Jul 29, 2010, at 5:40 PM, Eric

On Oct 25, 2009, at 1:58 PM, Graham Wakefield wrote: > Hi all, > > (Sorry if the answer to this is obvious - and thanks in advance~) > > Short version: > linker error of _backtrace from LLVMSystem.a building a dynamic > library embedding LLVM/clang, both against the OSX 10.4 sdk. > > Long version: > I've just tried rebuilding my project using the 2.6 release,

Hi, For the record, adding UNIVERSAL_SDK_PATH=/Developer/SDKs/MacOSX10.4u.sdk/ was insufficient to restrict the .a/.o files to link against the 10.4 sdk, but env MACOSX_DEPLOYMENT_TARGET=10.4 make did the trick. Thanks! On Jan 14, 2009, at 1:29 PM, Jean-Daniel Dupas wrote: > > Le 14 janv. 09 à 21:48, Chris Lattner a écrit : > >> >> On Jan 14, 2009, at 12:44 PM,

hello, I'm attempting to build the inferno source tree using either of native LTO or jit'd bins and having no obvious luck. im using macports (current as of this email) llvm-2.5 and llvm-gcc on a macbook pro (x86) following the inferno directions verbatim will use 'cc' as the compiler and just works. the build tools are different from the naive build tools as follows: