similar to: [LLVMdev] Times/Sizes of LLVMCore.o vs libLLVMCore.a

(Sorry, previous post got sent by accident. This is the real one) Folks, Here's some timing results looking at LLVM when it uses libLLVMCore.o vs. libLLVMCore.a. We're trying to decide which way to go and thought some data would help. The net of it is that using libLLVMCore.a is cheaper in both time and size of executables. We save 37 seconds on linking LLVMCore and about 1 minute 30

Here's the patch to build LLVM with libLLVMCore.a instead of LLVMCore.o. Could someone at Apple and someone at UIUC please try this? I want to make sure that its not just my build environment that improves with the use of libLLVMCore.a Thanks, Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: libVMCore.patch Type: text/x-patch Size: 7091 bytes Desc:

Hey all, I need to use C bindings in a pass that I am authoring (specifically, I want to use the OCaml bindings that are tied to the C bindings to author the pass). However, this requires that I link in LLVMCore to provide said bindings to my library. From what I've read, there is a known issue with linking LLVMCore into a module that is fed to opt. Namely, you get the following assertion:

you want to use the execution engine and JIT but do not put them in the llvm-config line?? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091106/d26a0a02/attachment.html>

On 12/26/12 12:32 AM, Rick Mann wrote: > I'm trying to make a library in Xcode that links against LLVM. I used the STL C++ template in Xcode 4.5.2, added libLLVMCore.a and libLLVMSupport.a to the link binaries phase, and made this call in my code: > > llvm::LLVMContext& llvmCTX = llvm::getGlobalContext(); > > I get link errors against std::string and other STL classes: >

Reid Spencer wrote: >There are some bugs against it that state the current progress. The >problem is that it depends on how the libraries are being used. Even if >you get past the linking problems, you will end up with re-registration >of passes and options, etc., which causes asserts. So, for now, there >aren't many good solutions. > > Is it possible to link opt and

I'm trying to make a library in Xcode that links against LLVM. I used the STL C++ template in Xcode 4.5.2, added libLLVMCore.a and libLLVMSupport.a to the link binaries phase, and made this call in my code: llvm::LLVMContext& llvmCTX = llvm::getGlobalContext(); I get link errors against std::string and other STL classes: Undefined symbols for architecture x86_64:

Has anything been done about this issue since Reid first mentioned it? I think I'm getting bitten by it. -- John T. Reid Spencer wrote: > The recent change in the library structure to make libLLVMCore.a instead > of LLVMCore.o has caused a little fallout. The problem is LLVM tools > that take a --load option to load a module dynamically may now cause > those modules to fail to

mingw, llvm 2.6 (buid with llvm-gcc) Example source code: http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html I change LLVMCreateJITCompiler(&engine, provider, &error); to LLVMCreateJITCompiler(&engine, provider, 3, &error); $ llvm-gcc `llvm-config --cflags` -c fac.c $ g++ `llvm-config --libs --cflags --ldflags core analysis executionengine jit

There are some bugs against it that state the current progress. The problem is that it depends on how the libraries are being used. Even if you get past the linking problems, you will end up with re-registration of passes and options, etc., which causes asserts. So, for now, there aren't many good solutions. Reid. On Thu, 2006-06-22 at 17:21 -0500, John Criswell wrote: > Has anything

The recent change in the library structure to make libLLVMCore.a instead of LLVMCore.o has caused a little fallout. The problem is LLVM tools that take a --load option to load a module dynamically may now cause those modules to fail to load at runtime. This occurs because the tool with the --load option might not be linking in all of libLLVMCore.a, but only the object modules actually needed by