similar to: [LLVMdev] Fedora packaging problem

Hi, I'm still working on the Fedora Extras package for LLVM. Because of the Fedora requirement that all packages in Extras be built from source, I must build the dreaded C Front End. :) I think I've mostly got things set up correctly, but I've found what I suspect is a tricky problem: make[1]: Leaving directory `/home/adam/rpmbuild/BUILD/llvm-1.8/llvm-gcc4-obj/gcc' Checking

Hello, > #1 0x00000033fc810c66 in _Unwind_RaiseException () from /lib64/libgcc_s.so.1 > #2 0x00000033fd4c3dbd in __cxa_throw () from /usr/lib64/libstdc++.so.6 What's your native gcc version? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi Michael, On Tue, 2007-01-16 at 13:13 +0800, Michael T. Richter wrote: > On Tue, 2007-16-01 at 02:50 +0000, Reid Spencer wrote: > > > The build instructions provided tell me to build llvm-gcc first from > > > the source. > > > The source for that tells me to build llvm first from the source. I'm > > > not sure where to go from this point. >

Hello, Paolo. > I hope this is usefull, I'm pretty new to OS X. Well. From your example you have got the only valgrind results: ==28336== 58 bytes in 2 blocks are possibly lost in loss record 70 of 127 ==28336== at 0x4020A92: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==28336== by 0x410010B: std::string::_Rep::_S_create(unsigned, unsigned,

I've created fink packaging for a building the llvm and llvm-gcc-4.2 svn pulls under fink on Mac OS X. Hopefully the fink info script and patch should be clear enough for some comments on my build approach. The llvm-gcc and llvm-g++ compilers seem okay so far. The llvm-gfortran compiler seems to always spew a warning.. WARNING: 128-bit integers not supported! ...even when just compiling a

I'm looking forward to your patches and bug reports. I really want to get this going myself. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Anton Korobeynikov Sent: Wednesday, May 10, 2006 1:22 PM To: LLVM Developers Mailing List Subject: [LLVMdev] Successfulyl bootsrapped llvm-gcc4 on mingw32 Hello, Everyone. Today

Hello, Everyone. All blackmagic (playing with pwd, etc) in my build description has gone with patched bash (pwd builtin was just hardly disabled). It's not good, I myself prefer modifying libstdc++ configure script to use PWD_CMD environmental variable as main gcc ones. I'm working on this feature. -- With best regards, Anton mailto:asl at math.spbu.ru

Hi, I have seen the bug http://llvm.org/bugs/show_bug.cgi?id=896 Maybe it is a non-issue but I had some trouble with this. I am running Debian sid and were no longer able to compile llvm. /home/fred/llvm/build/gcc/xgcc: /home/fred/llvm/build/gcc/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6) The installed version have this symbol. strings

Hello, all. Just found this file in my e-mail atchive, hope it will be useful for somebody. ===cut=here=== Some small rules: 1) No blankspace in the paths to the top-level directories. 2) Add paths to binaries to your system PATH variable. 3) Use short paths to top-level directories. 1. Some checks & preparations. 1) Be sure, that you're using right make version: $ make

On 6/25/2010 2:37 PM, Rafael Espindola wrote: > The linker (gold) requires you to pass -plugin to it. I am using the command: llvm-gcc a.c -emit-llvm -use-gold-plugin and here is the output: $LLVMGCCPREFIX/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/bin/ld: error: $LLVMGCCPREFIX/libexec/gcc/i686-pc-linux-gnu/4.2.1/libLLVMgold.so: could not load plugin library

On Mon, Oct 28, 2013 at 5:53 PM, Richard Smith <richard at metafoo.co.uk>wrote: > On Mon, Oct 28, 2013 at 5:13 PM, "C. Bergström" <cbergstrom at pathscale.com>wrote: > >> On 10/29/13 07:01 AM, Richard Smith wrote: >> >>> >>> [As an aside: I use libc++ for my Clang development (on Ubuntu Linux), >>> and it works for me (tm). This

Hello, Reid. You wrote Friday, January 21, 2005, 11:14:41 PM: RS> FYI, work progresses on the Win32 native port which you might also find RS> interesting. It might even get done before the cygwin stuff. Jeff Cohen RS> is working on that. Perhaps he can indicate the status of that effort. There is too much work to do native Win32 builds. I've tried to get llvm compiled on mingw32

When the support for h323plus was announced for Asterisk 1.4.25, I tried to build this support in Asterisk. For this, I checked out the h323plus CVS from SourceForge, which reported version 1.20.beta5, and also the ptlib-2.4.2 source RPM from Fedora 10. I finally managed to build a chan_h323 for Asterisk 1.4.25, which apparently loads correctly, but now I see that I get a segfault whenever I

Chris Lattner wrote: >>Why does llvm-gcc build its own libgcc_s.so? Would we have the same >>problem if we tried to build FSF GCC 4.01, or is this problem LLVM-specific? > > libgcc is part of the GCC distro. My (possibly flawed) understanding of > the issue is that GCC generates code that contains calls into libgcc. > This means that any code compiled with llvm-gcc

> So when I copy it to $PREFIX/libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/ and > $PREFIX/lib/bfd-plugins/, should I rename it to libLLVMgold.so? Any other > copies I should make? The copy in that directory can have any name you like. BFD will try all. Note that that is the copy that nm and ar will use. The linker (gold) requires you to pass -plugin to it. >> >> Copying it

Hi, I'm using the official 3.6 release binaries for x64 Linux. When compiling with warnings, I don't see any color diagnostics. Explicitly enabling -fcolor-diagnostics works fine. I have TERM set to xterm-256color. Any idea why? For what it's worth, I tried compiling LLVM/clang from trunk and color diagnostics work fine by default. Upon further investigation, I saw that the official

After the 7.2 upgrade?boost-openmpi-1.53.0-25 was installed, along with?openmpi-1.10.0-10. ?The old openmpi was then replaced with?compat- openmpi16-1.6.4-10. ?All fine. Except boost-openmpi has a dependency on the old libmpi.so.1 and the new openmpi has libmpi.so.12: # ldd libboost_mpi-mt.so.1.53.0? linux-vdso.so.1 =>??(0x00007ffe8c182000) libboost_serialization-mt.so.1.53.0 =>

Hello, Greg. You wrote Saturday, May 6, 2006, 10:24:16 PM: GP> If anyone has any insight I'd love to hear it. GP> Meanwhile, I'll continue to investigate... Currently I'm working on bootstrapping llvm-gcc4 on mingw32 platform. There are some serious miscompartibilities preventing build. I'll let know the results. Anyway, it's common knowledge, that msys itself have

On Tue, 2007-16-01 at 02:50 +0000, Reid Spencer wrote: > > The build instructions provided tell me to build llvm-gcc first from > > the source. > > The source for that tells me to build llvm first from the source. I'm > > not sure where to go from this point. > You should build llvm first, then llvm-gcc. When I build LLVM first, however, I get told that it

Hi, I'm trying to install RPM package Adobe Reader on Centos 6. I did a rpm -test -ivh on the package and it says it needs dependencies (many) Is a there a command to verify which exact packages it requires so I wont be installing software blindly. missing dependencies: error: Failed dependencies: libatk-1.0.so.0 is needed by AdobeReader_enu-9.4.2-1.i486 libc.so.6 is