similar to: [LLVMdev] Heads Up: libLLVMCore.a and loadable modules

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

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

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

Hi, While attempting to build the LLVM code from CVS today using gcc 4.1, I encountered the following error. Any idea how to proceed with the build? llvm[2]: Linking Debug executable llvm-as /home/ll/programs/source/scm/cvs/llvm/Debug/lib/libLLVMAsmParser.a(llvmAsmParser.o): In function `__static_initialization_and_destruction_0':

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

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

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:

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

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:

This is release_50 branch of git, sha1: f1d5723be3f9456a6b16cdf687847ac2918846de Using gcc 7.2.0 from homebrew. $ CC=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-gcc-7 CXX=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-g++-7 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/Users/andy/local/llvm5 -DCMAKE_PREFIX_PATH=/Users/andy/local/llvm5 $ make VERBOSE=1 [ 92%] Linking CXX

On 2009-09-24 22:34, hc2428 at columbia.edu wrote: > Dear developers, > When I try to map line numbers in source code back to LLVM > basicblocks, I meet some problems: there is a source file with 1500 > lines of code, but when I use BasicBlockPass to collect all > DbgStopPoint instructions in this file, I can only get 500 lines of code. > The source code and the collected

Dear staff, I downloaded an llvm version from the svn trunk at June 12, because the released 2.5 version can not support "gcc -g -Ox", and x=1,2,3. I use the version in svn to compile an httpd.bc file succefully with dbgstoppoint() functions. However, when I use llc to compile the bc file to .s file (llc -f -o httpd.s httpd.bc), I met this error (the httpd.bc file will be

On Fri, Dec 5, 2008 at 1:58 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Fri, Dec 5, 2008 at 1:57 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >> On Fri, Dec 5, 2008 at 1:52 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >>> / * snip */ >> >> Actually, rebuilding it makes "debug tblgen" fail with the errors at >> the

Hi, Recent trunk has a lot of failures on PPC64/Linux. One seems to be crash with a backtrace like: [ 3149s] -- [ 3149s] 0 libLLVMSupport.so 0x00003fff7ed0b864 llvm::sys::PrintStackTrace(_IO_FILE*) + 4294746876 [ 3149s] 1 libLLVMSupport.so 0x00003fff7ed0bb1c [ 3149s] 2 libLLVMSupport.so 0x00003fff7ed0c520 [ 3149s] 3 linux-vdso64.so.1 0x00003fff7f7b0478 __kernel_sigtramp_rt64 + 0 [ 3149s] 4

On Sat, Jun 5, 2010 at 3:18 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Tom, > > I'm pretty sure that the LLVMContext constructor is defined in libLLVMCore.a > What is the output of `llvm-config --libs bitwriter`?  Does it include > -lLLVMCore? Hi Duncan, e0082888 at e0082888-laptop:~$ local/bin/llvm-config --libs bitwriter -lLLVMBitWriter -lLLVMCore -lLLVMSupport

Hello Anton, While we have been discussing this, my partner discovered the source of where the sj/lj stuff is coming from. Does this mean that the LLVM libraries we're using are broken? Type.cpp ..\..\..\..\llvm\lib/libLLVMCore.a(Type.cpp.obj):Type.cpp.text+0x722): undefined reference to `__gxx_personality_sj0' ..\..\..\..\llvm\lib/libLLVMCore.a(Type.cpp.obj):Type.cpp.text+0x750):

Here there is the dump: SelectionDAG.cpp:81: static bool llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, const llvm::APFloat &): Assertion `VT.isFloatingPoint() && "Can only convert between FP types"' failed. 0 libLLVMSupport.so 0x00007f7405022de5 llvm::sys::PrintStackTrace(_IO_FILE*) + 37 1 libLLVMSupport.so 0x00007f74050232e3 2 libpthread.so.0

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