similar to: [LLVMdev] win32 still broken

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] win32 still broken"

2004 Sep 03
4
[LLVMdev] diffs for vc7.1
Hi all, Here the first bunch of patch for compiling part of LLVM under win32 with MSVC 7.1: * Trivial addings (I hope!): - #include <string> at top of: llvm\include\llvm\ExecutionEngine\ExecutionEngine.h(78) : error C2039: 'string' : is not a member of '_STL' - #include <algorithm> at top of: llvm\lib\CodeGen\LiveIntervalAnalysis.cpp(639) : error C2039:
2004 Dec 21
2
[LLVMdev] win32 broken again
Primitive Unix I/O should not be used outside of lib/System: c:\llvm\lib\Bytecode\Reader\ReaderWrappers.cpp(140) : error C2039: 'read' : is not a member of 'operator``global namespace'''
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
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
3
[LLVMdev] Little win32/Signals.cpp patch
Adding an include for std::remove under vc7.1 --- Paolo Invernizzi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040924/e1ca1218/attachment.txt>
2004 Dec 21
0
[LLVMdev] win32 broken again
Jeff, Thanks for reporting this. I had no idea ::read was being used in ReaderWrappers. I have re-implemented it using istream facilities. This should be much more portable. Please try again and let me know if its better. Thanks, Reid. On Mon, 2004-12-20 at 22:31, Jeff Cohen wrote: > Primitive Unix I/O should not be used outside of lib/System: > >
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
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 Dec 24
0
[LLVMdev] win32 broken again
Hi Jeff, Typically, I've found out that these missing functions are placed beneath lib/System/Unix in some of *.cpp files. These function can be copied to their respectively lib/System/Win32 *.cpp files. Henrik. ----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at
2004 Dec 24
3
[LLVMdev] win32 broken again
Well... that didn't take long. I'm not sure what you did, Reid, with Path.cpp, but it broke VC++: Bytecode.lib(ReaderWrappers.obj) : error LNK2001: unresolved external symbol "public: __thiscall llvm::sys::Path::Path(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0Path at sys@llvm@@QAE at
2004 Dec 23
3
[LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfileor 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 suchfileor directory Date: Thu, 23 Dec 2004 08:05:39 -0800 >Yes, it
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
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 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
2010 Nov 22
1
Using RInside in Visual Studio 8.0 VC++.NET Program
Hello, I am trying to use Rinside package in my VC++.Net program ( using Visual Studio 8.0 environment). I have downloaded Windows binary of RInside from the following link http://cran.r-project.org/web/packages/RInside/index.htm Version of RInside - 0.2.3 While compiling the program , i am getting about 69 error. Some of them are the folllowing ones. Please me in solving the following issue
2004 Dec 26
0
[LLVMdev] VC++: Cannot open include file: 'windows.h':No suchfileor directory
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
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 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----
2009 Nov 12
1
[ win32utils-Bugs-27425 ] win32-open3 doesn't build with 1.9.1
Bugs item #27425, was opened at 2009-11-11 21:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=27425&group_id=85 Category: win32-open3 Group: Code Status: Open Resolution: None Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: win32-open3 doesn''t build with 1.9.1 Initial Comment: Windows XP VC++ 9
2004 Dec 23
0
[LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfileor directory
Henrik Bach wrote: > ----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 suchfileor