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

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 data below was generated from using GCC 3.4.6 and binutils 2.15.92 on Fedora Core 3 running on a 2.4GHz Dual Xenon with 1GB of ram. Time With libLLVMCore.a With LLVMCore.o Link Real Time (-j 1) 2m12.592s 3m51.750s

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:

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

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

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

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

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: >

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:

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

While learning to write LLVM passes and following the precise instructions under http://llvm.org/docs/WritingAnLLVMPass.html, <http://llvm.org/docs/WritingAnLLVMPass.html> I got this error when loading the hello pass to run the test program: opt -load ./Release/lib/Hello.so -hello < test/test.bc > /dev/null Error opening './Release/lib/Hello.so': ./Release/lib/Hello.so:

Thank you, Reid. I have applied tha patch to ltdl.c ltdl.h. The problem still exists. I looked up the symbol on libLLVMCore.a, and found three U-entries and one T-entry. However, the Darwin linker is not able to find the T-entry. Any idea? pollux:~/test jingyu$ opt -load /Users/jingyu/tools/build-ppc/Release/lib/LLVMHello.so -help Error opening

Hey Chuck, I'm afraid I can't reproduce your error but...a problem you may run into later is that opt will complain with opt: llvm/lib/VMCore/Pass.cpp:149: void<unnamed>::PassRegistrar::RegisterPass(const llvm::PassInfo&): Assertion `Inserted && "Pass registered multiple times!"' failed. Aborted I "fixed" this by replacing the LLVMLIBS line in

Some additional information about the setup may be of interest: I'm using CMake to generate the make files for MSYS. All appears to go well until the tools are compiled. The undefined references seem to be coming from the libraries that were just compiled: ../../lib/libLLVMBitReader.a(BitcodeReader.cpp.obj):fake:(.rdata$linkonce_ZTVN4llvm8ConstantE+0x10): undefined reference to

Thanks, Shu, I guess I haven't updated since my post went out. There are actually 2 problems: 1. mis-compilation: My LLVM-2.5 turned out to be mis-compiled using gcc-4.4.0 (surprise to me) on Debian4-32b. I tried a few different compilers, and gcc-4.0.4 (a relatively old one, again surprised me) seems to work out fine. Question: is there a good/quick/reliable way to figure out whether a

Hello again, In order to avoid the set jump/long jump dependency of DLLs built under Visual C++, we're trying to build the libraries and tools under LLVM-GCC so it will use DWARF exception handling instead of SJ/LJ. The problem we're running into is that the libraries that we just finished creating cannot be found later in the build process when OPT tries to build. My partner has MinGW

Hi, I'm looking for some pointers on how to troubleshoot this problem. I'm trying to write a backend for the AVR. There is an undefined reference at line 48 which is the line FrameInfo() is on. I've tried to use the MSP430 and other targets as references so I'm not sure what changes I did would cause a problem on this line? AVRTargetMachine::AVRTargetMachine(const Target &T,

On Mon, 28 Aug 2006, Jing Yu wrote: I don't really have any ideas beyond what Reid has already said, but: > pollux:~/test jingyu$ opt -load > /Users/jingyu/tools/build-ppc/Release/lib/LLVMHello.so -help > Error opening '/Users/jingyu/tools/build-ppc/Release/lib/LLVMHello.so': > Can't open :/Users/jingyu/tools/build-ppc/Release/lib/LLVMHello.so: >

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,