similar to: Link error on Linux

Tried that just now, same result. On Fri, Mar 25, 2016 at 6:58 AM, Snehasish Kumar <kumar.snehasish at gmail.com> wrote: > Hi Russel, > > Can you try compiling aklo.o using -fno-rtti prior to linking? > > On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I'm trying to link a program with LLVM on Linux.

Yeah, seems to. a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv U _ZN4llvm4outsEv U _ZN4llvm4outsEv 0000000000000000 b _ZGVZN4llvm4outsEvE1S 0000000000000000 T _ZN4llvm4outsEv 0000000000000000 r _ZZN4llvm4outsEvE19__PRETTY_FUNCTION__ 0000000000000000 b _ZZN4llvm4outsEvE1S U _ZN4llvm4outsEv I can try building

Hi Russel, Can you try compiling aklo.o using -fno-rtti prior to linking? On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm trying to link a program with LLVM on Linux. I've managed to take out > the test files from 'llvm-config --libs' but now it's getting errors with > missing symbols. The same program

Since the log tells you that llvm::outs() is not found, and since it is supposed to be found in libLLVMSupport.a, you can try: $ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv ... 0000000000002070 T __ZN4llvm4outsEv ... The output should have the symbol defined. -- Mehdi > On Mar 25, 2016, at 12:18 AM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote:

Looking again at your link line, I think static library has to appear after their uses. So try to put the .o before the list of library. -- Mehdi > On Mar 25, 2016, at 12:41 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > > Yeah, seems to. > > a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv > U

Hello, Neal > You may want to note that you need glibc-devel.i386 to build. Otherwise you > get error on /usr/include/gnu/stubs-32.h missing. Do you have pure 64 bit system? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

You may want to note that you need glibc-devel.i386 to build. Otherwise you get error on /usr/include/gnu/stubs-32.h missing.

When I enabled this option I am getting errors, see below. Is there any way to fix this? There should be an option to have most of the code in shared library. Yuri --- error log using gcc-4.5.0 on 4 cpus with configure options: --enable-assertions --enable-optimized --enable-shared --prefix=/usr/local/llvm --- llvm[2]: Compiling llc.cpp for Release build gmake[2]: Entering directory

Hi all, On my Fedora 10 x86-64 the current svn dies in the following way: /home/maurice/installation/llvm-dev/utils/TableGen/Debug/TGLexer.o: In function `llvm::TGLexer::getNextChar()': /home/maurice/installation/llvm-dev/utils/TableGen/TGLexer.cpp:71: undefined reference to `llvm::TGSourceMgr::FindBufferContainingLoc(llvm::TGLoc) const'

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++ -I/n/fs/scratch/tpondich/ParallelAssert/llvm-objects/include -I/n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt

Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include

--enable-shared was _created_ in 2.7. If you were passing it in 2.6 or earlier, it wasn't doing what you expected. I just tried it again on trunk (not 2.7) on OSX 10.5, and it works. What platform are you on? Does it work with another version of gcc? On Tue, Apr 27, 2010 at 4:06 PM, Yuri <yuri at tsoft.com> wrote: > > When I enabled this option I am getting errors, see below.

On Mon, May 29, 2017 at 9:25 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to

Hi, On the OpenMandriva side, x86_64 passes all checks. We're having some problems with other architectures though (see below): x86_64 succeeded, packages are here: https://abf.openmandriva.org/build_lists/76792 i586 fails to build, but this seems to be an issue with 3.8.1 (which we're using to build 3.9): /usr/bin/clang++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS

It would be better, because a debug tablegen is slower than an optimized tablegen, but it's still slow and it doesn't address the problem that tablegen runs *at all* when it doesn't really need to. I think if tablegen wasn't running all the time we could incremental builds down from 15 minutes (and that's on my really powerful machine) to under 5, which seemed like a big

For a bit of an experiment I've been trying to compile LLVM & Clang with -Weverything (disabling any errors that seem like more noise/less interesting). One warning I've recently hit a few instances of is -Wweak-vtable which is, in fact, an explicitly documented LLVM coding standard ( http://llvm.org/docs/CodingStandards.html#ll_virtual_anch ). Some instances of this have been easy to

On Saturday 19 December 2009 00:16, Chris Lattner wrote: > > Or I think I can just assume (Yikes!) that if the signal handler is > > invoked it will really be a circular_raw_ostream since the handler > > should (!) only be set up in debug mode. > > > > That scares me a bit, though. > > Why don't you just check #ifndef NDEBUG like the code that sets it up?

Dear testers, 3.9.0-rc1 was just tagged from the 3.9 branch at r277207. This took a little longer than I'd hoped, but I think the branch is in a decent state now. There are still open merge requests and bugs, but I'd like to get the real testing started to see where we're at. Please build, test, and upload binaries to the sftp. Let me know how it goes. I'll upload source, docs,

Hello, There is an issue in the latest Sparc code: while we can encode POPC, decode results in crash in llvm-mc $ echo "popc %g1, %g2" | ./Release+Asserts/bin/llvm-mc -assemble -triple=sparcv9 -show-encoding .text popc %g1, %g2 ! encoding: [0x85,0x70,0x00,0x01] $ echo "0x85,0x70,0x00,0x01"|./Release+Asserts/bin/llvm-mc -disassemble -triple=sparcv9

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >