Displaying 20 results from an estimated 8000 matches similar to: "[LLVMdev] Files to lib/System/Win32"
2004 Sep 14
1
[LLVMdev] Files to lib/System/Win32
>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
2004 Sep 14
0
[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
2004 Dec 21
3
[LLVMdev] VC++: Cannot open include file: 'windows.h': No such file or directory
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
----------------
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 Sep 15
0
[LLVMdev] diffs for vc7.1
>From: Jeff Cohen <jeffc at jolt-lang.org>
>Date: Wed, 15 Sep 2004 10:29:15 -0700
>
>It all depends on how well it works with 7.1. Hopefully it won't be
>much longer before we know for sure.
>
When, we have found the compiler that compiles LLVM code, we should use it
as the lowest dominator for all future releases as long as possible due to
those issues stated in
2004 Sep 14
2
[LLVMdev] Files to lib/System/Win32
>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
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 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!
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 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 Sep 14
0
[LLVMdev] Files to lib/System/Win32
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
2004 Sep 15
1
[LLVMdev] Files to lib/System/Win32
>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,
2004 Sep 15
2
[LLVMdev] Files to lib/System/Win32
>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
2005 Jan 28
0
[LLVMdev] Compiling errors for tracelib.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
2005 Jul 12
0
[LLVMdev] MASM Backend
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
2004 Sep 14
1
[LLVMdev] Files to lib/System/Win32
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
2004 Sep 02
0
[LLVMdev] Native win32 port
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
2004 Dec 14
2
[LLVMdev] Linking tblgen: undefined reference to `llvm::sys::Path::Path(std::string)'
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':
2004 Sep 28
1
[LLVMdev] Linking tblgen debug executable (without symbols) onMinGW
>From: Jeff Cohen <jeffc at jolt-lang.org>
>Date: Sat, 25 Sep 2004 15:26:56 -0700
>
>Yes. You need to link with dbghelp.lib and psapi.lib. There are
>pragmas to force this, but not surprisingly gcc does not honor Microsoft
>pragmas.
I can't find the above libs. Where are they located on your system?
Are there any dll pendants?
Henrik
2004 Sep 29
1
[LLVMdev] Linking tblgen debug executable (without symbols)onMinGW
>From: Jeff Cohen <jeffc at jolt-lang.org>
>Date: Tue, 28 Sep 2004 13:05:16 -0700
>
>They are part of the Platform SDK from Microsoft, part of Visual Studio.
>They correspond to Window system DLLs dbghelp.dll and psapi.dll in
Arrrggg, I forget this relation...
>\winnt\system32. If you do not have these libs, then you are out of
>luck. Mingw should have provided them