similar to: [LLVMdev] LLVM tools sufficient to build the cfrontend for windows from MinGW?

The problem with building the frontend on Windows is that gcc cannot be bootstrapped using Window's native compiler -- i.e. VC++ -- unlike every other platform. It can be built on Windows using gcc, of course, but even then only if the entire GNU environment is present. The real problem is that the bootstrapped frontend binaries built using gcc may not properly link with LLVM binaries built

On Tue, 2 Nov 2004, Jeff Cohen wrote: > The problem with building the frontend on Windows is that gcc cannot be > bootstrapped using Window's native compiler -- i.e. VC++ -- unlike every > other platform. It can be built on Windows using gcc, of course, but > even then only if the entire GNU environment is present. Yeah, annoying. Unfortunately we're not up to fixing GCC :)

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

Hi, In my experiments, I need to disable several linking optimizations. However, bzip2, vortex and eon failed if "-disable-opt" was passed to gccld. I tried the out-of-box llvm and the building process provided by llvm-test. The same problem was observed, when I specified EXTRA_LINKTIME_OPT_FLAGS = -disable-opt on Makefile.program and simplied typed "make" under

I know that Al Stone has compiled llvm-gcc4 successfully and I can report the same. The problem I consistently run into is that llvm-gcc ends up producing native format output; it does not produce bytecode, nor does it invoke gccas or gccld. I'm using the latest svn, and my configure args are: --prefix=/work/scottm/llvm-cfrontend/obj/../i686-pc-linux-gnu \

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

Cyrille Mescam wrote: > On Mon, Jun 13, 2005 at 11:02:10AM -0500, John Criswell wrote: > >>Cyrille Mescam wrote: >> [snip] > > In fact, i am using the CFE build procedures. I am on instructions 5. > > cyrille > Okay, I took a closer look at your output. I was correct in that gccas is attempting to assemble a native PPC assembly language file. However,

On Mon, Jun 13, 2005 at 11:02:10AM -0500, John Criswell wrote: > Cyrille Mescam wrote: > >Hi, > > > > > >When compiling the cfrontend for Linux/PPC architecture on a powermac > >G5, i got > >the following error : > > I hate to ask a silly question, but are you using "make bootstrap" to > build the cfrontend? Your output looks like gccas

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

Hi, When compiling the cfrontend for Linux/PPC architecture on a powermac G5, i got the following error : -------------------------------Compilation error listing if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi make GCC_FOR_TARGET="/usr/local/home/cyrille/project/llvm/cfrontend/build/gcc/xgcc -B/usr/local/home/cyrille/project/llvm/cfrontend/build/gcc/

Branches have been created. You are free to checkin to cvs head again. I'll send mail once I have the prerelease tar balls up. Please continue to review and revise the documentation. I can fold this into the release later. Thanks, Tanya On Thu, 13 Apr 2006, Tanya Lattner wrote: > > I will be creating the release branch at 1:00pm PDT. Please refrain from > checking in from

I will be creating the release branch at 1:00pm PDT. Please refrain from checking in from 1:00-1:30pm. I will send email once I am done. Thanks, Tanya

Hi, I cannot find windows either... In previous llvm sources windows.h was found in: 'include/llvm/Config'. ------ Build started: Project: support, Configuration: Release Win32 ------ Compiling... randtable.c c:\projects\src\llvm-1\llvm\lib\Support\bzip2\bzlib.h(117) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory huffman.c ----------------

On Apr 4, 8:06 pm, heisenbug <ggr... at gmail.com> wrote: > On Apr 4, 7:51 pm, Török Edwin <edwinto... at gmail.com> wrote: > > > > > heisenbug wrote: > > > On Apr 3, 10:53 pm, Gabor Greif <ga... at mac.com> wrote: > > > ... > > > >>> 3) Make sure that make check and some reasonable subset of llvm-test > > >>>

On Thu, 9 Sep 2004 20:16:37 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > On Thu, 9 Sep 2004 08:52:10 -0700 > Jeff Cohen <jeffc at jolt-lang.org> wrote: > > > > I haven't got around to this yet but I will. The odds are good the > > > problem is in a BSD system header file so I need to capture the > > > preprocessed source. > > >

On Fri, 4 Apr 2008, heisenbug wrote: >> point taken. thanks! > > > Whatever I try I get something like this: > > ggreif$ cd MultiSource/ > ggreif$ make > make[2]: *** No rule to make target `Output/be.bc', needed by `Output/ > burg.linked.rbc'. Stop. > make[1]: *** [Burg/.makeall] Error 2 > make: *** [Applications/.makeall] Error 2 This is the

Cyrille Mescam wrote: > Hi, > > > When compiling the cfrontend for Linux/PPC architecture on a powermac > G5, i got > the following error : I hate to ask a silly question, but are you using "make bootstrap" to build the cfrontend? Your output looks like gccas is being given a native code assembly language file to parse, and I seem to recall that that happens if

Hi, Is it necessary to use the VC6.1+ `__time64_t' type instead of __time_t in win32/TimeValue.cpp? --------------- In file included from c:/projects/src/llvm-1/llvm/lib/System/TimeValue.cpp:51: c:/projects/build/MinGW/llvm-1-1/lib/System/platform/TimeValue.cpp: In member function `std::string llvm::sys::TimeValue::toString() const':

>So, if I'm understanding you correctly, libdgbhelp is a library that >doesn't come with MinGW but can be installed on MinGW by the user if it is >needed. Am I correct? Yes. >If that's the case, I would say that it's the user's reponsibility to >install the library into /usr/lib or provide the configure script with the >appropriate -L options to find it

Hi I noticed that these defines (line 35 to 37) are hardcoded in the DataTypes.h include file: ---------------- #define HAVE_SYS_TYPES_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_STDINT_H 1 ---------------- Shouldn't they have be defined by the configure script into llvm/Config/config.h? Henrik _________________________________________________________________ Undg� pop-ups med MSN Toolbar