similar to: [LLVMdev] Fedora packaging problem

Building llvm-gcc4 on Linux requires a little modification to a Makefile. Attached is a patch to insert the following notice into the README.LLVM in llvm-gcc4. Here's the text of the patch, for those that are building llvm-gcc4: On more recent systems (e.g. Fedora Core 5), where the version of libgcc_s.so used by libstdc++.so is more recent than the version used by llvm-gcc, you will get an

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

On Sun, 2006-10-29 at 19:39 -0500, Adam Goode wrote: > 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:

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

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

Fredrik Svensson wrote: > It is just the LD_LIBRARY_PATH that brings in the "llvm" libgcc_s.so.1 > that breaks the compilation. > > I added this to my build script and now llvm builds properly. > > cd build > ../llvm-gcc4/configure --prefix=$LLVM/install --enable-llvm=$LLVMOBJDIR > --enable-languages=c --disable-threads > sed -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

Hi, I'm trying to track down some nasty glibc failures on Linux. I think the problem is that my system compiler (3.4.6) doesn't match llvm-gcc (4.0.x) so when the llc compiled programs run they don't quite get the right libstdc++. If I run a test program with: LD_LIBRARY_PATH=/path/to/my/llvm-gcc4/libs Output/sieve.llc then I get this: Output/sieve.llc: symbol lookup error:

This is an libpath problem. When xgcc runs it wants to dynamically link the libgcc.so. When you run it from the command line it will find your system libgcc.so (which works) and so you don't see the segfault. When you run xgcc from the Makefile, it will have set LD_LIBRARY_PATH to get your <cfebuilddir>/gcc directory which will find the libgcc.so that it just built, which is the one

So, I'm trying to build everything from source for the Debian package for LLVM, including the C/C++ front end. I'm running this build on LLVM 1.4 source (the released tarball), using Debian unstable (gcc 3.3.5, on a 2.6.8 kernel, on an x86_64 box, dual CPU). Before I get _too_ deep into it, I thought I would ask if the following compilation failure on the CFE looks the least bit familiar

Reid Spencer wrote: > This is an libpath problem. When xgcc runs it wants to dynamically linkthe libgcc.so. > When you run it from the command line it will find yoursystem libgcc.so (which works) Not really. For systems that have gcc 4.2 natively installed, like the current Debian testing, the compiler gets GCC_4.2.0 version errors. It isn't easy to work around b/c xgcc wants to link

yes, so this happens on anything that uses a struct for va_list (like alpha). I am currently working on fixing this. if you look at the last patch to the alpha portion of llvm-gcc, you can see a quick hack to work around that (aka, get it to compile), but the resultant compiler will have issues with varargs. Alternately, build ia-32 binaries on x86_64, llvm-gcc is happy with the the abi there.

On Sat, 2006-06-03 at 11:25 -0700, Reid Spencer wrote: > I don't think anyone has successfully built llvm-gcc4 on Linux yet. I've > tried and failed. I've successfully built and used llvm-gcc4 on linux/alpha Andrew

Hi Scooter, On Mon, 2006-11-06 at 12:07 -0800, Scott Michel wrote: > Reid Spencer wrote: > > This is an libpath problem. When xgcc runs it wants to dynamically linkthe libgcc.so. > > When you run it from the command line it will find yoursystem > libgcc.so (which works) > > Not really. For systems that have gcc 4.2 natively installed, like the > current Debian

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=utf-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Reid,<br> <br> Here's the backtrace you asked for:<br> <br>

I'm trying to get LLVM1.9 working on my Ubuntu 6.10 system. The LLVM version in the repositories is 1.7 and I've never managed to get it successfully working because whoever packaged it thought it would be fun to rename everything. This means I can't use it to build 1.9 and I've therefore decided to try bootstrapping a 1.9 build. Yes, I've looked at the docs where it said

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=us-ascii" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <b>Reid,<br> <br> I followed the steps but got stuck as described

On Thu, 28 Sep 2006, Nick Lewycky wrote: > Thanks for that workaround. What I've been doing is copying > /lib/libgcc_s.so.1 over LLVM's copy and rebuilding xgcc. > > A long-term fix for this would be nice. I'm not hitting this, so I'm relying on you guys to figure out what the right solution is. > Why does llvm-gcc build its own libgcc_s.so? Would we have the same

I'm having some trouble getting llvm-gcc4 to compile. It's unable to compile darwin-crt3.c. It's mentioning "Complex expression. Absolute segment assumed." but I'm not sure if that's a real error message. Has anyone run into this before? I'm running on a G4 apple 10.4.8, kernel version 8.6.0. I googled around and found a bug with the same error message:

In trying to package up LLVM for Debian, it appears that x86_64 is no longer a supported architecture -- so, my first question is, is that correct? Best I can tell, the only thing that's supposed to work for x86_64 is the C backend. For Debian, I need to build everything from scratch. When trying to build llvm-gcc4 from source, though, I get part way through the build and am told that