Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] VC++: Cannot open include file: 'windows.h': No such file or directory"
2004 Dec 22
0
[LLVMdev] VC++: Cannot open include file: 'windows.h': No such file or directory
Windows.h is part of Microsoft's Platform SDK that's bundled with Visual
Studio. It should never have been in the llvm source tree. Why don't
you have it? You have VC++, right?
Henrik Bach wrote:
> Hi,
>
> I cannot find windows either... In previous llvm sources windows.h was
> found in: 'include/llvm/Config'.
>
> ------ Build started: Project:
2004 Nov 02
5
[LLVMdev] LLVM tools sufficient to build the cfrontend for windows from MinGW?
Hi,
I'm able to build the llvm tools on the MinGW platform: burg, fpcmp, tblgen,
llvm-as, llvm-dis, opt, gccas, llc, llvm-link, lli, gccld, llvm-stub,
analyze and extract.
I wonder if these tools are sufficient to start build the cfrontend?
Henrik.
_________________________________________________________________
Undg� pop-ups med MSN Toolbar - http://toolbar.msn.dk hent den gratis!
2004 Dec 14
2
[LLVMdev] __time_t type instead of __time64_t in win32/TimeValue.cpp
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':
2004 Dec 14
1
[LLVMdev] __time_t type instead of __time64_t inwin32/TimeValue.cpp
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
2004 Dec 23
2
[LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfile or directory
----Original Message Follows----
From: Jeff Cohen <jeffc at jolt-lang.org>
Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List
<llvmdev at cs.uiuc.edu>
To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': No
suchfile or directory
Date: Tue, 21 Dec 2004 16:29:47 -0800
2004 Dec 14
0
[LLVMdev] __time_t type instead of __time64_t in win32/TimeValue.cpp
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:
>
2004 Dec 21
2
[LLVMdev] The vc++ solution cannot live in parallel with a mingw compilation
Hi Jeff and Morten
Does anyone of you win32 guys have the guts to move the sed results from
*.in files out of the llvm source folders and place them under llvm/win32
instead?
Then, as I see it, I will be able to to build both vc++ and mingw versions
from the same sources. And, that would be nice. Otherwise, the vc++ solution
mess up with my mingw compilation.
Henrik.
2004 Sep 25
2
[LLVMdev] Hardcoded HAVE_* defines in the DataTypes.h include file
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
2004 Dec 23
0
[LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfile or directory
Yes, it should find windows.h with the default configuration. But you
have to be suspicious of beta code that Microsoft gives out for free.
It might just be very buggy, or it might be deliberately crippled.
Considering the price tag on Visual Studio, it's one or the other (and
probably both).
Out of curiosity, did it accept the solution and project files as is, or
did it want to
2004 Dec 21
1
[LLVMdev] llvm vc++ Bytecode/Bytecode.vcproj is missing
Hi Jeff,
It seems that the above project isn't committed into cvs.
Henrik.
=============================================================
Henrik Bach
Open Source Developer
e-mail: henrik_bach_llvm at hotmail.com
=============================================================
Got Freedom?
Software Freedom Day 2004 - 28th of August
http://www.softwarefreedomday.org/
2005 Jul 11
3
[LLVMdev] MASM Backend
Here's the new MASM backend.
It has the following files :-
lib/Target/X86/X86AsmPrinter.h
lib/Target/X86/X86AsmPrinter.cpp
lib/Target/X86/X86MASMPrinter.h
lib/Target/X86/X86MASMPrinter.cpp
lib/Target/X86/X86.td
lib/Target/X86/X86InstrInfo.td
lib/Target/X86/makefile
Makefile.rules
win32/x86/x86.vcproj
2004 Oct 25
1
[LLVMdev] Link error with TOOLLINKOPTS=-ldbghelp on MinGW
>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
2005 Jan 28
2
[LLVMdev] Compiling errors for tracelib.c
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"
2004 Nov 02
0
[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
2004 Oct 25
1
[LLVMdev] Link error with TOOLLINKOPTS=-ldbghelp on MinGW
>From: John Criswell <criswell at cs.uiuc.edu>
>Will this library be needed for tblgen or for all LLVM programs? And is it
>a library you wrote for LLVM, or is it a MingW library?
It's is generally needed for all programs or at least programs using
Signals.o (from platform/Signals.cpp) and it is platform/MinGW specific.
>TOOLLINKOPTS is used by configure to convey
2004 Sep 15
2
[LLVMdev] HowToUseJIT.cpp - file: 'llvm/ADT/iterator': No such file or directory
Hi
I'm trying to compile HowToUseJIT.cpp, but it seems that iterator definition
is missing:
--------------------Configuration: HowToUseJIT - Win32
Debug--------------------
Compiling...
HowToUseJIT.cpp
c:\sfu\usr\local\src\llvm\include\llvm\adt\ilist(41) : fatal error C1083:
Cannot open include file: 'llvm/ADT/iterator': No such file or directory
Error executing cl.exe.
I've
2004 Oct 18
1
[LLVMdev] Compiling errors from OptimizerDriver.cpp when compiling on MinGW
Hi,
I didn't get a clear idea what to do whit this problem:
OptimizerDriver.cpp seems to be unix platform specific. However, I'm
compiling this on MinGW. Shouldn't this be moved to lib/System/<platform>?
Any suggestions?
--------------------------
c:/Projects/src/llvm/tools/bugpoint/OptimizerDriver.cpp:28:22: sys/wait.h:
No such file or directory
2004 Dec 25
2
[LLVMdev] VC++: Cannot open include file: 'windows.h':No suchfileor directory
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----
2004 Nov 02
1
[LLVMdev] LLVM tools sufficient to build the cfrontend for windows from MinGW?
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 :)
2004 Dec 26
1
[LLVMdev] VC++: Cannot open include file:'windows.h':No suchfileor directory
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