similar to: [LLVMdev] Little win32/Signals.cpp patch

Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] Little win32/Signals.cpp patch"

2004 Sep 24
0
[LLVMdev] Little win32/Signals.cpp patch
But I compiled that under vc7.1 as it was! On Fri, 24 Sep 2004 15:19:22 +0200 Paolo Invernizzi <arathorn at fastwebnet.it> wrote: > Adding an include for std::remove under vc7.1 > > --- > Paolo Invernizzi >
2004 Sep 24
6
[LLVMdev] Little win32/Signals.cpp patch
<algorithm> works too. On Fri, 24 Sep 2004 10:09:21 -0500 Alkis Evlogimenos <alkis at cs.uiuc.edu> wrote: > On Fri, 2004-09-24 at 09:43, Paolo Invernizzi wrote: > > Jeff Cohen wrote: > > > > >But I compiled that under vc7.1 as it was! > > > > > > > > ;-(( > > > > Probably is an implicid includes, but I'm using the
2004 Sep 24
4
[LLVMdev] Little win32/Signals.cpp patch
I'll wait for the research. We should try, as much as possible, to make it work with just what the compiler provides and without third party packages. Thanks, reid. On Fri, 2004-09-24 at 07:46, Jeff Cohen wrote: > I added the include of cstudio and it fails with plain VC7.1; the file > does not exist. > > Add it for now. If it is impossible to build with VC7.1 and without
2004 Sep 24
2
[LLVMdev] Little win32/Signals.cpp patch
Someone needs to adjudicate on whether I add the #include of <cstdio> or not. I can't test this so, Paolo/Henrik/Jeff, please let me know if I need to add it. Thanks, Reid. On Fri, 2004-09-24 at 07:08, Jeff Cohen wrote: > But I compiled that under vc7.1 as it was! > > On Fri, 24 Sep 2004 15:19:22 +0200 > Paolo Invernizzi <arathorn at fastwebnet.it> wrote: > >
2004 Sep 24
2
[LLVMdev] Little win32/Signals.cpp patch
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
2004 Sep 24
0
[LLVMdev] Little win32/Signals.cpp patch
Jeff Cohen wrote: ><algorithm> works too. > > For std::remove yes... but... d:\home\arathorn\sandbox\llvm\llvm\lib\System\platform\Signals.cpp(179) : error C2065: 'stderr' : undeclared identifier d:\home\arathorn\sandbox\llvm\llvm\lib\System\platform\Signals.cpp(179) : error C3861: 'fprintf': identifier not found, even with argument-dependent lookup
2004 Sep 24
0
[LLVMdev] Little win32/Signals.cpp patch
I checked right now that it compiles also with #include <iostream> Jeff, can you test it with plain VC? --- Paolo Invernizzi On Sep 24, 2004, at 4:52 PM, Reid Spencer wrote: > I'll wait for the research. We should try, as much as possible, to make > it work with just what the compiler provides and without third party > packages. > > Thanks, > > reid. > >
2004 Sep 24
0
[LLVMdev] Little win32/Signals.cpp patch
I added the include of cstudio and it fails with plain VC7.1; the file does not exist. Add it for now. If it is impossible to build with VC7.1 and without STLPort, then there really isn't a choice. I have to research the issue myself to see if it's possible to avoid using STLPort. On Fri, 24 Sep 2004 07:42:51 -0700 Reid Spencer <reid at x10sys.com> wrote: > Someone needs
2004 Sep 24
1
[LLVMdev] Little win32/Signals.cpp patch
On Fri, Sep 24, 2004 at 05:32:08PM +0200, Paolo Invernizzi wrote: > Jeff Cohen wrote: > > ><algorithm> works too. > > > > > For std::remove yes... but... > > d:\home\arathorn\sandbox\llvm\llvm\lib\System\platform\Signals.cpp(179) > : error C2065: 'stderr' : undeclared identifier >
2004 Sep 23
2
[LLVMdev] struct and class under VC7.1
On Sep 23, 2004, at 4:08 PM, Jeff Cohen wrote: > MSVC++ is picky about this. It considers classes and structs to be > different types so you have to be consistent. If you forward declared > a > struct as a class within the same compilation unit, it would complain > about that too. It's not just linking. You are right... BTW, I've just fixed that problem in my checkout
2004 Sep 23
2
[LLVMdev] struct and class under VC7.1
Hi all, Finally I managed to find out a strange problem under Visual C During the link of the HowToUseJIT program, I was always missing some symbols... and I was going crazy testing out different options... At the end, unmangling the differences in what linker was searching and what was present in the libraries, I found that the problem is that we have something like this... Value.h struct
2004 Sep 23
0
[LLVMdev] struct and class under VC7.1
I have just committed a change to Value.h that changes the Value class from using a "struct" declaration to a "class" declaration. I'm not sure why VC7.1 would generate different symbols for class vs. struct. I'm pretty certain that's a violation of the ABI. In any event, we should be consistent. The Value class is declared "class Value" in numerous places
2004 Sep 24
4
[LLVMdev] Little win32/Signals.cpp patch
It would be great to avoid STLPort and use plain vanilla VC... as I told, the biggest difference it's how the hash_map and hash_set are implemented, but I'm not so strong in C++ for resolving the iussue. About the build procedure, it's based on scons, and it's still at a very preliminary stage... Right now I'm trying to build TableGen with it, as till now I've always
2004 Sep 23
0
[LLVMdev] struct and class under VC7.1
MSVC++ is picky about this. It considers classes and structs to be different types so you have to be consistent. If you forward declared a struct as a class within the same compilation unit, it would complain about that too. It's not just linking. On Thu, 23 Sep 2004 15:59:42 +0200 Paolo Invernizzi <arathorn at fastwebnet.it> wrote: > Hi all, > > Finally I managed to find
2004 Oct 07
2
[LLVMdev] RE: MinGW Tablegen
Hi As requested from Paolo, I've sent him the tablegen tool. The tool is able to compile the td files (given in the makefile) on windows without any complaints. Henrik >From: Paolo Invernizzi <arathorn at fastwebnet.it> >Date: Thu, 7 Oct 2004 14:27:11 +0200 > >Hi Henrik, > >As you may remember, I'm trying to use the LLVM core tools under Visual >Studio.
2004 Sep 24
0
[LLVMdev] Little win32/Signals.cpp patch
Uh... this may be a silly question, but why can't you include <stdio.h>? It'd be much better than <iostream>. Anyway, I think I'll try this weekend to come up with my own way of building on Win32. I prefer that building on Windows depends only on Microsoft and GNU tools, and the fewer of the latter the better. My gut instinct is to capture all the files generated by
2004 Sep 15
4
[LLVMdev] diffs for vc7.1
Hi, Has some one committed these patches into CVS? Paolo, thanks for the patches. In the near future I'll try to compile them. I've installed STLport 6.4.2 with vc6. Henrik --- Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/ --- >From: Paolo Invernizzi <arathorn at fastwebnet.it> >Reply-To: LLVM Developers Mailing List
2004 Sep 15
1
[LLVMdev] diffs for vc7.1
On Sep 15, 2004, at 8:04 PM, Jeff Cohen wrote: > I cannot find any specific instructions for uninstalling the VC++ 2005 > Express Edition. There is this README file: > http://lab.msdn.microsoft.com/express/visualc/readme/default.aspx. As > it isn't the full Visual Studio it probably isn't messing around with > Windows system files. > > I do know for a fact that the
2004 Sep 15
2
[LLVMdev] diffs for vc7.1
On Sep 15, 2004, at 7:29 PM, Jeff Cohen wrote: > Just make sure you read the uninstall instructions before installing. > Microsoft has been known to essentially require the reformatting your > boot partition in order to uninstall beta versions of VS. And, of > course, it is required that you uninstall the beta before installing a > newer beta or the release version. Urrggg! I
2004 Sep 24
0
[LLVMdev] Little win32/Signals.cpp patch
OK. I strongly support that sentiment. Paolo, could you send me your procedure for building under Windows? I haven't tried to build anything but System/Win32 so far. On Fri, 24 Sep 2004 07:52:23 -0700 Reid Spencer <reid at x10sys.com> wrote: > I'll wait for the research. We should try, as much as possible, to make > it work with just what the compiler provides and without