similar to: [LLVMdev] LLVM as shared libraries

Axel Naumann <Axel.Naumann at cern.ch> writes: > is there an option to build LLVM's libs (and maybe clangs, but that's > for later :-) as shared libraries? It's not --enable-shared :-) If it > doesn't exist: is there any interest to have it? It would reduce my > build time considerably... With cmake it is BUILD_SHARED_LIBS http://www.llvm.org/docs/CMake.html

Hi Óscar, On 2009-10-08 00:49, Óscar Fuentes wrote: > Axel Naumann <Axel.Naumann at cern.ch> writes: >> is there an option to build LLVM's libs (and maybe clangs, but that's >> for later :-) as shared libraries? > > With cmake it is BUILD_SHARED_LIBS > > http://www.llvm.org/docs/CMake.html Great! So I must use CMake instead of configure / make to get

Hi Keno, The part that scares me a bit is > and then adjust the other methods to not > bail out two quickly when encountering a weak symbol. I would very much appreciate if you could implement this; I don't have enough knowledge of the MCJIT nor llvm CodeGen internals... I will happily try it out and provide you with feedback, though! :-) Thank you *so* much for your fast reaction!

2009/8/31 Axel Naumann <Axel.Naumann at cern.ch>: > we want to implement a C++ interpreter using LLVM and clang Isn't clang going on that direction anyway? cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm

Hi, we want to implement a C++ interpreter using LLVM and clang, to replace our existing one <http://root.cern.ch/drupal/content/cint> that is used as part of a data handling and analysis environment <http://root.cern.ch>. We plan to keep the set of features that our current interpreter offers, e.g. calls into and out of libraries, dynamic scoping, unloading of code, and a prompt. I

Hi, I'm finally moving cling to MCJIT - and MCJIT is wonderful! So far I only ran into this issue: $ cat linkonceodr.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T StaticStuff<T>::s_data = 42; int compareAddr(int* mcjit); #ifdef BUILD_SHARED int compareAddr(int* mcjit) { if (mcjit

Hi, I ran into a problem migrating cling (finally!) to MCJIT: When an ("outer") MCJIT's finalization / llvm::RuntimeDyldImpl::resolveExternalSymbols() is called and a symbol is not known, cling can help by loading the suitable library and providing the symbol. It compiles the relevant C++ header as part of loading the library. This compilation emits symbols through the MCJIT. That

On Mon, Oct 5, 2009 at 8:27 PM, Axel Naumann <Axel.Naumann at cern.ch> wrote: > Hi, > > #include "JIT.h" will do. Thanks. That was exactly what I needed to progress to the next error ("Unable to find target for this triple (no targets are registered)") As soon as I get this front-end working with the trunk, I'll start submitting patches that add calls to

Hi, This is a question on how to resolve weak symbols from the binary for symbols that are also llvm::Module-local. Currently, the JIT seems to favor resolving to module-local symbols over existing symbols: $ cat symbols.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T

Hi, #include "JIT.h" will do. Cheers, Axel. On 2009-10-06 03:09, Kenneth Uildriks wrote: > I've gotten my front-end to compile with the 2.6 branch and with trunk > (not with both; I have to fiddle with a few things when switching), > and it refuses to give me an execution engine. > > My link flags include everything coming from "llvm-config --libs". >

I've gotten my front-end to compile with the 2.6 branch and with trunk (not with both; I have to fiddle with a few things when switching), and it refuses to give me an execution engine. My link flags include everything coming from "llvm-config --libs". Nevertheless, the error string coming back from ExecutionEngine::create is: JIT has not been linked in Is this a known problem?

Hi, I've been trying to find a list of the current JIT-supported targets. Not easy :-) The sources seem to say that the architectures are X86, PowerPC, ARM, Alpha. And then their obvious combination with Linux, FreeBSD / MacOSX, Win32 - is that it? Cheers, Axel.

On Jan 20, 2009, at 5:56 AM, Axel Naumann wrote: > Hi, > > I've been trying to find a list of the current JIT-supported > targets. Not easy > :-) The sources seem to say that the architectures are X86, PowerPC, > ARM, > Alpha. And then their obvious combination with Linux, FreeBSD / > MacOSX, Win32 - > is that it? X86-64 and PPC64 also. I don't know how

On Aug 31, 2009, at 1:19 PM, Renato Golin wrote: > 2009/8/31 Axel Naumann <Axel.Naumann at cern.ch>: >> we want to implement a C++ interpreter using LLVM and clang > > Isn't clang going on that direction anyway? Clang is meant to be flexible enough to be used as the basis for a C++ interpreter. However, there will probably be a bit of work to do in Clang to make

Dear experts, I am trying to learn and use llvm, and I built llvm 2.6 with gcc 4.3.2 on linux. I encountered an issue to resolve now. 1. Is there any option to build all the llvm libraries to shared library files with .so extension? Currently most of the library files come with .a extension which are static, and only two libLTO.so and libprofile_rt.so files are in .so ( shared ) forms.

Hi Chris, Chris Lattner wrote on 10/15/2009 05:45 PM: > On Oct 15, 2009, at 8:29 AM, Anton Korobeynikov wrote: >> >> I'm a bit curious: is there any reason why are other slides / videos >> not available (it seems that the ones missing are from Apple folks)? > > Unfortunately, we found out at the last minute that Apple has a rule > which prevents its engineers

> On Jan 14, 2016, at 11:22 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Jan 14, 2016, at 9:38 AM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >>> On Jan 14, 2016, at 5:18 AM, Dan Liew <dan at su-root.co.uk> wrote: >>> >>> On 14 January 2016 at 11:24, David Jones via llvm-dev

James Williams <junk at giantblob.com> writes: > I don't actually need opt dynamically linked but I do want shared > libraries. The cmake build should work: http://www.llvm.org/docs/CMake.html BUILD_SHARED_LIBS:BOOL Flag indicating is shared libraries will be built. Its default value is OFF. Shared libraries are not supported on Windows and not recommended in the other

> On Jan 14, 2016, at 5:18 AM, Dan Liew <dan at su-root.co.uk> wrote: > > On 14 January 2016 at 11:24, David Jones via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Thanks - I'll try this tonight. >> >> Assuming it works, should these variables be added to the docs at >> http://llvm.org/docs/CMake.html ? > > Yes. It probably makes

Hi, Thanks for getting back to me. I don't actually need opt dynamically linked but I do want shared libraries. If run make without "SHARED_LIBRARY=1" I don't appear to get any shared libraries built or installed. Is LLVM built as shared libraries supported? If so what's the correct build procedure? -- James On 2 March 2010 21:51, Jeffrey Yasskin <jyasskin at