similar to: [LLVMdev] LLVM 3.2: conflict with Ubuntu 12.04's version 3.0 of LLVM

Alan, > Hi, > > I am working on a Qt project which relies on various plugins, one of which being an LLVM plugin which I build from the LLVM 3.2 source code. Everything works fine on Windows and OS X, but not on Ubuntu 12.04. Did you use configure/Make or CMake to build llvm-3.2? > > Basically, my application runs fine, but when I close it I get a "Segmentation fault (core

Alan Garny <agarny at hellix.com> writes: > Basically, my application runs fine, but when I close it I get a > "Segmentation fault (core dumped)". Debugging my application, I found > out that, upon shutting down, my application tries to call Ubuntu's > version of LLVM (see below for the debug trace). To convince myself > that it was really the case, I sudo

Thanks a lot Reid. It’s much appreciated. I am going to apply your to my local copy of LLVM 3.6 and see how it goes. Cheers, Alan. From: Reid Kleckner [mailto:rnk at google.com] Sent: 01 April 2015 18:56 To: Alan Garny Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Workaround for Bug 22963? Thanks for the poke. I fixed the issue in r233819. It'll be in the next point

No, I am currently using MSVC 2013 Update 3. Why? Is there something I should (have) know(n)? Alan From: Zachary Turner [mailto:zturner at google.com] Sent: 10 March 2015 17:40 To: Alan Garny; llvmdev Subject: Re: [LLVMdev] LLVM 3.6: problems building on Windows using MSVC 2013 To be certain, are you using MSVC 2013 Update 4? On Tue, Mar 10, 2015 at 9:18 AM Alan Garny <agarny

Hi, >From what I have seen on this mailing list and elsewhere, it would seem that it isn't possible to build LLVM as a shared library using Visual C++. Still, I would imagine that quite a few people are or would be interested in it, so. is there any plan to support this any time soon? This, unless it's already supported in some way or another which I am not aware of.? I have been

> > So… my question is: why?! More importantly: what do I need to do to be > > able to export/import a class such as clang::driver::Compilation? > > It looks like MSVC is trying to synthesize and export the copy assignment > operator and copy constructur. This is interesting, as I thought it wouldn't do > that if the class turns out not to be non-copyable. > >

Hi, I have recently upgraded my project to LLVM 3.6 and I am wondering whether I should have waited for version 3.6.1. With JIT having been officially superseded by MCJIT, I updated my code and got everything working fine on 64-bit Windows, 32-bit/64-bit Linux and OS X, but it's not working properly on 32-bit Windows. Basically, the issue I am having is similar to the one reported in

Óscar Fuentes <ofv at wanadoo.es> writes: > Michael Spencer <bigcheesegs at gmail.com> writes: > > The problem is that MSVC++ requires sprinkling > > __declspec(dllexport/dllimport) all over the code, and we really don't > > want to deal with maintaining that, as most developers have little to > > no experience with Windows DLLs. > > BTW, you

Sorry, I am using CMake+JOM or CMake+Ninja, if Ninja is available on the developer’s machine. Either way, it fails in both cases with a message similar to the one I included below (which was obtained using CMake+Ninja). Just in case, my (current) CMakeLists.txt file can be found at here

On Sat, Apr 7, 2012 at 11:58 PM, Alan Garny <agarny at hellix.com> wrote: > Óscar Fuentes <ofv at wanadoo.es> writes: > > Michael Spencer <bigcheesegs at gmail.com> writes: > > > The problem is that MSVC++ requires sprinkling > > > __declspec(dllexport/dllimport) all over the code, and we really don't > > > want to deal with maintaining

It seems to be that LLVM doesn't make sense as a shared library. The surface area of the interface is massive, and in constant flux. I would think in real world situations, a domain specific interface with a more focused public interface would the right solution. On Fri, Apr 6, 2012 at 6:15 PM, Alan Garny <agarny at hellix.com> wrote: > Hi,**** > > ** ** > > From what I

There are a variety of "real world situations," some of them would benefit from shared-library packaging and some would not. Say you're building a set of tools for internal deployment in your large-ish organization. Factoring out the Clang/LLVM bits into a shared library can reduce memory footprint when running multiple tools, reduce disk footprint which therefore reduces antivirus

On Fri, Apr 6, 2012 at 6:15 PM, Alan Garny <agarny at hellix.com> wrote: > Hi, > > From what I have seen on this mailing list and elsewhere, it would seem that > it isn’t possible to build LLVM as a shared library using Visual C++. Still, > I would imagine that quite a few people are or would be interested in it, > so… is there any plan to support this any time soon? This,

Hi, I need to build a shared version of LLVM on Windows, Linux (both x86 and x64) and Mac OS X. So far, I have been able to build LLVM on Linux and Mac OS X, and it's all working fine as confirmed by a small LLVM test code that I wrote. However, on Windows, even though I get a DLL, that DLL doesn't contain any (exported) functions (according to DLL Export Viewer; see

Ok, I have just found the cause of the error messages I am getting, and it now makes sense to me why the 'normal' build works fine on Windows, Linux and OS X, and why my personal build works on Linux and OS X, but not on Windows. However, I still don't understand why I am getting the error messages I am getting. Anyway, it has to do with wanting to export some classes and function,

Hi, I have been using LLVM+Clang in my project for some time and it has been working just fine up to now (I am currently using version 3.5.1). However, with version 3.6 having just been released, I thought I would give it a try and update my code to use MCJIT rather than the now discontinued JIT. Well, this proved to be a relatively smooth process, and everything is now working fine on

Hi Takumi, > > Otherwise, > > I haven't installed binutils since I don't seem to need it.? > > You need binutils, esp. ld, nm, objdump. > > FYI, how to browse export table in DLL with objdump; $ objdump -x > XXX.dll Ok, I got the latest version of binutils from http://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/. > > As you can tell, I am

I am trying to figure out how to free up some memory that seems to be lost when running valgrind under our internal application. The stack traces I get are: ==19966== 4 bytes in 1 blocks are still reachable in loss record 1 of 12 ==19966== at 0x402569A: operator new(unsigned int) (vg_replace_malloc.c:255) ==19966== by 0x5D9BBE8: void* llvm::object_creator<llvm::PassRegistry>()

On Friday 10 August 2007 17:55, David Greene wrote: > On Friday 10 August 2007 15:12, David Greene wrote: > > Perhaps an easier way is to just expose the -simple-register-coalescing > > and -conservative-register-coalescing options to the user, but I don't > > know how to do that on an individual pass bases. opt just jams then all > > in with PassNameParser.

Hi, I'm Ryo Onodera. This is my first post to this mailing list. Fist, thanks for creating a great library! We're using LLVM to support JIT in Rubinius (an alternative implementation of Ruby, a dynamic programming language). I'm submitting a small patch for a minor issue. It solves still-reachable leak warnings from Valgrind. Example warnings are shown at the end of this mail. As