similar to: [LLVMdev] More on Cygwin

LLVMers, If you're not working from the CVS "head", you can ignore this. Otherwise, please read it! I have committed changes to CVS head that require changes to your build environment. This is part of PR432. The changes involve getting the CFE to build an executable named llvm-gcc instead of gcc. The hyphenated name was chosen to be consistent with other LLVM tools, it is also

On Thu, 19 Aug 2004 08:45:23 -0700 Reid Spencer <reid at x10sys.com> wrote: > > I'm running FreeBSD 5.2.1 with gcc 3.3.3. I had some problem starting > > the build as I had to get linux binary emulation to work. (The problem > > here is that FreeBSD can be made compatible with 5 different distros, > > and not all of them work with LLVM. I used linux_base-8;

On Nov 19, 2004, at 9:25 PM, Mohd-Hanafiah Abdullah wrote: > Dear Dr Vikram: > > I need to know how to invoke llvmg++ so that it generates C code. Here's how you can do a single file (i.e., an unlinked executable): llvmg++ -c infile.cpp -o - | llc -march=c -o infile.cbe.c Reid might be able to tell you how to do it with a single command using the llvmc tool. In future, please

Hi Chris, > Also note, LLVM 1.4 will be released in the next few days, so if waiting is > an option, you might choose to do so. Alright, I've got llvm and llvm-gcc from RELEASE_14 cvs and tried building it under cygwin. 1) The first problem is with llvm in SysUtils.c: int executeProgram(const char *filename, char *const argv[], char *const envp[]) { ................ execveTy

Building with --enable-llvm failed latter on when compiling libojc: configure:5099: checking for exception model to use configure:5131: /home/rafael/dev/gcc/build/gcc/xgcc -B/home/rafael/dev/gcc/build/gcc/ -B/i686-pc-linux-gnu/bin/ -B/i686-pc-linux-gnu/lib/ -isystem /i686-pc-linux-gnu/include -isystem /i686-pc-linux-gnu/sys-include -c -xobjecti ve-c -fgnu-runtime -fobjc-exceptions -S conftest.c

hi, when build test echo.cpp using "llvmg++ echo.cpp -o echo" it create an echo file, contain: ------------------------------------- [yue at RH9 Shootout-C++]$ cat echo #!/bin/sh lli \ -load=/usr/lib/libm.so \ $0.bc $* --------------------------------------- and using "llvmgcc echo.cpp -o echo-c", it creates an echo-c file, contain:

Chris Lattner wrote: >On Sun, 15 Aug 2004, Robert Feldt wrote: > > > >>However, I wonder if someone supplies pre-built cfrontend binaries for >>cygwin? >> >> > >Nope, we don't have one yet, sorry. > > > >>I followed the instructions and tried to build them myself but get >>when building the cfrontend. Any ideas? >>

hi, I try to build hello.cpp using both llvmg++ and GNU g++, the generate llvm bytecode's size is about 960K, and the size of binary code generated by g++ is only 13K. Could anyone explain the difference between the two result? BWT: I rebuild the cfrontend in RH linux9.0, but when I build the hello.cpp the llvmG++ reports warnings too, it shows: ----------------------------- [yue at RH9

On Mon, Aug 16, 2004 at 01:07:39PM +0200, Robert Feldt wrote: > However, when I go back to rebuild llvm, reconfigure, setting the > CFEINSTALL dir, then make it can build the tools ok but not the > runtime: [snip] > Compiling crtend.c to bytecode > Files/ATI: not found [snip] > I don't understand the error message since I see no reference to > Files/ATI. Any clues? Can

Ignore this at your own peril. I have committed changes to CVS that introduce a fully functional llvm-ar tool, and a new lib/Linker library that uses the archive's symbol table to hasten linking. However, this implies that archives read by the LLVM tools *must* have an LLVM symbol table in them. This happens automatically for the crtend.a library, but not for the runtime libraries produced by

Hi Reid Spencer, > CC=/path/to/llvmgcc CXX=/path/to/llvmg++ configure > make > > and was able to reproduce the problem. Not sure what's up with that but > as Misha pointed out, llvmgcc isn't any "particular" version of 3.4, its > just 3.4ish. I also concur with him that you should file a bug and > attach the pre-processed source to it. You can get that with

On Fri, 21 Apr 2006, [UTF-8] Rafael Esp?ndola wrote: > To work aroud the problem I edited gcc/objc/config-lang.in and removed > the comment from the line > #target_libs=target-libobjc > > With this change it is again possible to build without objc. The > complete configure line was > > ../llvm-gcc4-1.7.source/configure --prefix=$CFEINSTALL > --enable-languages=c,c++

Hi, I recently bootstrapped gcc4 frontend on a i686-linux-gnu too. As I notice, if the llvm "tools-only " was build with srcdir != objdir , the building of llvm-gcc4-1.7.source encountered mistakes of unable to find some header files. So I just edited llvm-gcc4-1.7.source/gcc/Makefile.in and a line like this: INCLUDES += -I$(LLVMOBJDIR)/include With this change, the building errors

Wow... it is nearly twice as fast. But it tried to install stuff in /usr/local (and as I wasn't root...) and it didn't do that before. As I don't care about profiling or tracing, I didn't bother to su and do it again. On Wed, 10 Nov 2004 23:45:35 -0800 Reid Spencer <reid at x10sys.com> wrote: > The entire makefile system was rewritten a couple of weeks ago. This is

The entire makefile system was rewritten a couple of weeks ago. This is a good thing, your compiles now go twice as fast. Resistance is futile, just adapt :) The install target installed the bytecode libs into CFEINSTALL as before and also installs the native libraries to your prefix/lib directory. This is intentional. Reid On Wed, 2004-11-10 at 23:32, Jeff Cohen wrote: > But there already

hi, when i build hello.cpp, it show following conflict: ----------------------------------------------------------- [yue at RH9 Shootout-C++]$ llvmg++ hello.cpp -o hello WARNING: Type conflict between types named 'struct._Unwind_Exception'. Src='{ ulong, void (uint, \4 *) *, uint, uint }'. Dest='{ ulong, void (ubyte, \4 *) *, uint, uint }' gccld: error linking in

I've encountered a few bugs including ICE and reject-valid when compiling a program with llvmg++ which compiles fine with standalone g++. Should I report those to your bugzilla or is it likely that these bugs are gcc bugs in the version of gcc you're using? if so, are there any plans to port the frontend to a newer gcc? (gcc 4.0 will be out in a few weeks) the versions: llvm 1.4 from

I forgot to mention .. This is a temporary requirement. I am working on changes so that an archive file that doesn't have a symbol table can be linked successfully, albeit a LOT slower. Reid. On Sun, 2004-11-14 at 15:41, Reid Spencer wrote: > Ignore this at your own peril. > > I have committed changes to CVS that introduce a fully functional > llvm-ar tool, and a new

On Wed, 2004-08-18 at 22:14, Jeff Cohen wrote: > I'm another new person to LLVM. Hi Jeff. Welcome. > I can't successfully compile and > execute a simple C++ program. The compiler seems to work, as it > produces a.out and a.out.bc files, but I get a whole bunch of warnings: > > WARNING: Found global types that are not compatible: >

The default prefix is /usr/local but I would recommend that when you configure LLVm you do so with: configure --prefix=/me/llvm/install/dir ... so that installation occurs in a place you have write access. If you feel strongly about restoring the install-bytecode target, feel free to file a bug. Reid. On Thu, 2004-11-11 at 09:12, Jeff Cohen wrote: > Wow... it is nearly twice as fast. But