similar to: [LLVMdev] Files to lib/System/Win32

>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

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.

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 Tue, 14 Sep 2004 12:46:31 +0200 "Henrik Bach" <henrik_bach_llvm at hotmail.com> wrote: > >From: Jeff Cohen <jeffc at jolt-lang.org> > >Date: Mon, 13 Sep 2004 21:24:47 -0700 > > > > > >But there are some issues with System I'm going to have to take care of > >besides using Win32. There appears to be some Unix assumptions like the

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

I think the $HOME and /etc assumptions are very limited in nature. Most of us who use LLVM every day here at UIUC don't need to bother installing anything in $HOME or /etc, and so they shouldn't be considered a major stumbling block for building a version of LLVM that runs on Windows, no matter how it is done or what libraries it is linked with. Making it possible to build LLVM on

>From: Jeff Cohen <jeffc at jolt-lang.org> >Date: Mon, 13 Sep 2004 21:24:47 -0700 > > >But there are some issues with System I'm going to have to take care of >besides using Win32. There appears to be some Unix assumptions like the >presence of /etc or the HOME environment variable. Neither have any >true equivalent in Windows. > Will be fixed in a working

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

>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 <jeffc at jolt-lang.org> > > >Date: Mon, 13 Sep 2004 21:24:47 -0700 > > > > > > > > >But there are some

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

>From: Jeff Cohen <jeffc at jolt-lang.org> >Date: Tue, 14 Sep 2004 19:43:34 -0700 > >OK, I stand corrected: mingw can be used to create honest-to-goodness >Windows applications using Win32. But you're still using it as a Unix >emulator :) > OK, if POSIX.1 is unix emulation then we have that all *nix emulates all *nix and that's fine with me :) OK, I admit,

>From: Jeff Cohen <jeffc at jolt-lang.org> >Date: Wed, 15 Sep 2004 10:35:36 -0700 > >What's a "compiling mesh?" What I meant, was that there are some implicit defines in mingw (like __GCC) and vcX (like _MVC) but possibly also other unsupported? internal structures. As I stated earlier mingw should be win32 api compliant, but not for complicating matters. But

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, 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"

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

I agree completely with you, Jeff. However, I think it somehow would be nice, if you guys could tell comming users that the win32 solution is geared toward VC++ 7.1 (and hence use of other tools are at their own risk). And, I think it also would be really cool, if you guys come up with a solution how to handle multiple VC++ x solutions/projects from the same source, possibly ranging from VC

Sure, we appreciate as much help we can get on this subject, too. Please, write to me, if you're interested in doing a port to native win32. /Henrik >Paolo, > >In addition to Brian's comments, please note that we're currently >consolidating the platform-specific code into a single library: >lib/System. Henrik Bach has signed up to provide both the Interix and

It's a possibility, though it would be better to create whole separate trees for different versions of VS. It's not just the project and solutions that need to be kept separate; the object files themselves cannot be mixed between different versions of VS. There's no rush though. Trust me, C/C++ programmers will not rush to adopt Whidbey once it's released. You'd be

On Wed, 15 Sep 2004 19:59:01 +0200 "Henrik Bach" <henrik_bach_llvm at hotmail.com> wrote: > >From: Jeff Cohen <jeffc at jolt-lang.org> > >Date: Wed, 15 Sep 2004 10:35:36 -0700 > > > > >What's a "compiling mesh?" > > What I meant, was that there are some implicit defines in mingw (like __GCC) > and vcX (like _MVC) but

Hi Jeff and Morten, I was just wondering if below wisdom is true, why not prefix every solution and project file with VC71 in front of the file name to signal the case that it is only designed for that specific IDE/tool? This gives us room for comming up with other solution and project files for another MS specific IDE/tool independt of each other. Henrik. ----Original Message Follows----