similar to: [LLVMdev] Native win32 port

> Are you interested in taking in account the possibility that the LLVM > source code could be compiled with Microsoft compiler on windows? If you think it's not too far off, then we'd be happy to consider patches, insofar as they increase LLVM's C++ standards compliance. > Most of the problems are pretty trivial... for example: > > - A lot of .cpp lacked the

Hi all, I've read with interest the threads of August about a win32 port (without cygwin), and as a joke yesterday I tried compiling LLVM on win32 with VC7.1, targeting the HowToUseJIT example... Well, apart from obvious problems, it went pretty well. I cannot reach the end of the process, but I'm feeling it's not too far. So the point is: Are you interested in taking in account

>From: "Henrik Bach" <henrik_bach_llvm at hotmail.com> >Date: Sat, 18 Sep 2004 18:46:26 +0200 >MAXPATHLEN is on Interix defined in <limits.h>. > >However, it doesn't seem to have any effect including it before any other >header files in the system specific Path.cpp for Interix as seen above: >--------------------------------- >#include

>From: "Henrik Bach" <henrik_bach_llvm at hotmail.com> >Date: Tue, 14 Sep 2004 18:10:29 +0200 > >>From: Jeff Cohen <jeffc at jolt-lang.org> >>Date: Tue, 14 Sep 2004 07:25:11 -0700 >> >>On Tue, 14 Sep 2004 12:46:31 +0200 >>"Henrik Bach" <henrik_bach_llvm at hotmail.com> wrote: >> >> > >From: Jeff Cohen

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

>From: Jeff Cohen <jeffc at jolt-lang.org> > >Uh... shouldn't a Win32 port use the Win32 API? > Well, as I see it LLVM contains only tools that are perfectably manageble through a shell. And in this respect, I see the win32/mingw port perfectably achieves this at the moment. >On Tue, 14 Sep 2004 02:11:51 +0200 >"Henrik Bach" <henrik_bach_llvm at

I'm not sure. Perhaps Jeff Cohen knows as he wrote this. Reid. On Tue, 2004-12-14 at 11:51, Henrik Bach wrote: > 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: >

Replace __time_t with time_t in my question. I've compiled function: std::string TimeValue::toString() const { // Alas, asctime is not re-entrant on Windows... //hb: __time64_t ourTime = this->toEpochTime(); time_t ourTime = this->toEpochTime(); //hb: char* buffer = ::asctime(::_localtime64(&ourTime)); char* buffer = ::asctime(::localtime(&ourTime)); std::string

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 Fri, 28 Jan 2005, Henrik Bach wrote: > Is there something wrong with my llvm-gcc compiler?: > c:/projects/src/llvm-4/llvm/runtime/libtrace/tracelib.c:54: warning: type > defaults to `int' in declaration of `PRIMES' > c:/projects/src/llvm-4/llvm/runtime/libtrace/tracelib.c:56: warning: data > definition has no type or storage class It looks like that file had

Hi, I'm linking tblgen. However, I get below error. I can't figure out what's wrong here. Could it be this statement in the Path.h: mutable std::string path; ///< Storage for the path name. ------------------ llvm[2]: Linking Debug executable tblgen c:/projects/build/MinGW/llvm-1-1/utils/TableGen/Debug/TableGen.o(.text+0x19da): In function `main':

Hi I've been investigating which characters that cause troubles: Length = 23 WhatsInBuffer=include "../Target.td" assert=false tblgen: Assertion failed: "Buffer[Length-1] == '"'", file FileLexer.l, line 128 idx hex char 0 69 i 1 6E n 2 63 c 3 6C l 4 75 u 5 64 d 6 65 e 7 20 8 22 " 9 2E . 10 2E . 11 2F / 12 54 T 13 61 a 14 72 r 15 67 g 16 65 e 17 74 t 18

Hi, Is there something wrong with my llvm-gcc compiler?: ------------------------ GNU C version 3.4-llvm 20030924 (experimental) (mingw32) compiled by GNU C version 3.4.1 (mingw special). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 c:/projects/src/llvm-4/llvm/runtime/libtrace/tracelib.c:54: error: syntax error before "PRIMES"

To be more specific: Lines containing SIGALRM and alarm(). >From: "Henrik Bach" <henrik_bach_llvm at hotmail.com> >Date: Fri, 24 Sep 2004 23:21:58 +0200 > >>From: Reid Spencer <reid at x10sys.com> >>Date: Fri, 24 Sep 2004 13:03:44 -0700 >> >>I just discovered that the *only* place this is used is in the debugger >>when it is loading

Hi LLVM'ers, has anyone read the license details for MASM32 and understood how these fit in with Open Source projects, especially GPL? - As far as I can see - no one is allowed to license projects under GPL or at worst other OS licenses nor the deritives of the project, if you're using MASM32. Are the MASM backend compatible with the MS version of MASM or other not so license

Hi Jeff, thanks for the patch, I'll try it in a few moments. If it doesn't compile, I'll leave it until you submit another patch :) >From: Jeff Cohen <jeffc at jolt-lang.org> >Date: Sat, 18 Sep 2004 12:01:13 -0700 >First, the Win32 version still has a lot of code in common with Unix. >This code should be pulled out into a common file. Sounds resonable.

>From: Paolo Invernizzi <arathorn at fastwebnet.it> >Date: Thu, 16 Sep 2004 10:20:39 +0200 > >I'm using scons to generate that files from .in files. I implemented in it >the configure check regarding iterators, hash and so on... >something like: > Hey, you've found the tool that makes it possible to generically reading Makefiles... Cool - The tool I've

Jeff Cohen wrote: >But I compiled that under vc7.1 as it was! > > ;-(( Probably is an implicid includes, but I'm using the STLPort standard library for LLVM (because it's not possible to use hash_map and hash_set of microsoft) cl /nologo /TP /EHsc /GR /Zi /Yd /D__STDC_LIMIT_MACROS /DHAVE__FINITE_IN_FLOAT_H /DHAVE__ISNAN_IN_FLOAT_H /DHAVE_WINDOWS_H

>From: Chris Lattner >Date: Thu, 7 Jul 2005 11:26:48 -0500 (CDT) > >On Thu, 7 Jul 2005, Henrik Bach wrote: >>The 'pthread_once' is located in the native library binary file: >>/usr/lib/libpthread.a. I've also included the path to the library in >>LLVM_LIB_SEARCH_PATH environment variable. > >If libpthread.a is a static library, lli won't be

Hi Misha, Files downloaded. Thank you very much. Henrik. From: Misha Brukman <brukman at uiuc.edu> Date: Mon, 8 Nov 2004 11:17:25 -0600 On Sat, Nov 06, 2004 at 09:35:47AM +0100, Henrik Bach wrote: > Would some one be so kind to catch the output when configuring and building > the CFE together with the log files produced? http://misha.brukman.net/code/llvm/logs/ The