Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] IsNAN.cpp:23:3: #error "Don't know how to get isnan()""
2004 Jul 18
1
[LLVMdev] IsNAN.cpp:23:3: #error "Don't know how to get isnan()"
Hi Brian
Here's the config.log (I'm not posting it on the dev-list).
The automatic gcc macro for Interix is __INTERIX if this is to any help.
/Henrik
>From: "Brian R. Gaeke" <gaeke at uiuc.edu>
>Reply-To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
>To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
>Subject: Re: [LLVMdev]
2004 Jul 16
2
[LLVMdev] IsNAN.cpp:23:3: #error "Don't know how to get isnan()"
Hi
>From: Chris Lattner <sabre at nondot.org>
>Date: Thu, 15 Jul 2004 17:43:27 -0500 (CDT)
>Ah, suddenly everything makes sense. If you're interested in LLVM on the
>windows platform, *please* get CVS.
Last night I've got the latest version of LLVM from CVS and now porting LLVM
to Interix from this version on.
I got this error:
---------------------
gmake[1]:
2004 Jul 06
1
[LLVMdev] CommandLine.cpp:189: error: `strdup' undeclared
Hi
>
>Are you able to explain below meaning to me?
>
>#if defined(_ALL_SOURCE) \
> || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE_EXTENDED==1)) \
> || (__STDC__ - 0 == 0 && !defined(_POSIX_C_SOURCE))
>extern char* __cdecl strdup(const char *);
>#endif /* defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE_EXTENDED == 1) */
>
(RTFM) Some of the above
2004 Oct 19
0
[LLVMdev] Visual C Patches for IsNAN.cpp and IsInf.cpp
I submitted a patch keeping the traditional approach,
HAVE_FINITE_IN_FLOAT_H and HAVE_ISNAN_IN_FLOAT...
Just another case added to the others instead of a custom approach.
---
Paolo
On Oct 19, 2004, at 12:16 PM, Morten Ofstad wrote:
> I don't know if Paolo submitted his patches for these files, but they
> are not in the CVS -- I've chosen a slightly different strategy,
>
2004 Jul 02
1
[LLVMdev] CommandLine.cpp:189: error: `strdup' undeclared
Hi Guys
I'm trying to port and build LLVM to the Interix environment. I've succeded
until the Interix version of gcc program executes:
gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support'
gmake[1]: Leaving directory `/usr/local/src/llvm/lib/Support'
gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support'
Compiling CommandLine.cpp
CommandLine.cpp: In function
2004 Jul 15
0
[LLVMdev] Constants.cpp:368: error: `INT8_MAX' undeclared(firstuse this function)
On Fri, 16 Jul 2004, Henrik Bach wrote:
> >There is currently support for building in non-cygwin windows environments
> >protected by _MSC_VER. You just need to broaden the scope of the #ifndef
> >to include internix.
> >
>
> Sorry Chris, but my DataTypes.h.in seems to be outdated (due to I'm porting
> LLVM 1.2), so I'm not at the moment able to edit the
2004 Jul 15
2
[LLVMdev] Constants.cpp:368: error: `INT8_MAX' undeclared(firstuse this function)
>From: Chris Lattner <sabre at nondot.org>
>Date: Wed, 14 Jul 2004 14:49:01 -0500 (CDT)
>
>There is currently support for building in non-cygwin windows environments
>protected by _MSC_VER. You just need to broaden the scope of the #ifndef
>to include internix.
>
Sorry Chris, but my DataTypes.h.in seems to be outdated (due to I'm porting
LLVM 1.2), so I'm not
2004 Jul 27
1
[LLVMdev] ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (firstuse this function)
Hi John,
Please see below, too
>From: John Criswell <criswell at cs.uiuc.edu>
>Date: Tue, 27 Jul 2004 14:57:02 -0500
>
>Henrik Bach wrote:
>>Hi,
>
>Please see below.
>
>>
>>I get this error:
>>------------------
>>ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (first use this function)
>>ToolRunner.cpp:396: error: (Each
2004 Jul 27
1
[LLVMdev] ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (firstuse this function)
Hi again
Does cygwin support shared libraries. And if not, how did you port llvm on
this issue?
/Henrik
>From: "Henrik Bach" <henrik_bach_llvm at hotmail.com>
>Date: Tue, 27 Jul 2004 00:41:53 +0200
>
>Hi,
>
>I get this error:
>------------------
>ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (first use this function)
>ToolRunner.cpp:396:
2004 Jul 03
1
[LLVMdev] CommandLine.cpp:189: error: `strdup' undeclared
Hi Guys
I'm trying to port and build LLVM to the Interix environment. I've succeded
until the Interix version of gcc program executes:
Before the patch:
gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support'
gmake[1]: Leaving directory `/usr/local/src/llvm/lib/Support'
gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support'
Compiling CommandLine.cpp
2004 Jul 03
1
[LLVMdev] CommandLine.cpp:189: error: `strdup' undeclared
On Sat, 3 Jul 2004, Chris wrote:
>
>That should work fine. I'm not familiar at all with internix, but it
>appears to have a buggy header or something. From what I understand,
>internix is a posix layer for windows. Have you tried compiling under
>cygwin?
No, not yet.
>If you grab the latest CVS sources, they should work fine with
>cygwin, and will probably work
2004 Jul 04
0
[LLVMdev] CommandLine.cpp:189: error: `strdup' undeclared
>From: Misha Brukman <brukman at uiuc.edu>
>Date: Sat, 3 Jul 2004 19:33:12 -0500
>Well, the patch adds #include <cstring> to CommandLine.cpp, so you
>should try the patch first. If it does not work, then the Interix SDK
><cstring> is not a fully complete substitue for <string.h>, which it
>should be, then you may have to manually try changing the
2004 Jul 05
0
[LLVMdev] CommandLine.cpp:189: error: `strdup' undeclared
Hi
I've found below declaration of strdup in /usr/include/string.h.
But, I'm wondering why it doesn't belong to the ordinary function prototypes
as extern char * __cdecl strcpy(char *, const char *);.
Are you able to explain below meaning to me?
#if defined(_ALL_SOURCE) \
|| (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE_EXTENDED==1)) \
|| (__STDC__ - 0 == 0
2004 Jul 14
1
[LLVMdev] Constants.cpp:368: error: `INT8_MAX' undeclared (firstuse this function)
>From: John Criswell <criswell at cs.uiuc.edu>
>Date: Wed, 14 Jul 2004 09:11:03 -0500
>
>
>The DataTypes.h header file is generated by the configure script and placed
>into your build tree. My best guess is that your system's header files do
>not correctly define these macros, so they are missing.
>
I did a search on the build and source trees, but neither
2004 Sep 16
1
[LLVMdev] Patch to lib/System/Interix
>From: Reid Spencer <reid at x10sys.com>
>Date: Thu, 16 Sep 2004 13:26:09 -0700
>
>Okay, so the question is, how do you do the equivalent of a MAP_ANON
>allocation on Interix. We don't want to map a file here. We're just asking
>for virtual memory (unbacked by swap or file) to be allocated to the
>process. Is there a way to do that on Interix? The
2004 Jul 14
0
[LLVMdev] Constants.cpp:368: error: `INT8_MAX' undeclared(firstuse this function)
>From: Chris Lattner <sabre at nondot.org>
>Date: Wed, 14 Jul 2004 14:49:01 -0500 (CDT)
>The file you need to modify is here:
>llvm/include/Support/DataTypes.h.in
>
>There is currently support for building in non-cygwin windows environments
>protected by _MSC_VER. You just need to broaden the scope of the #ifndef
>to include internix.
>
Sorry, Chris, but my
2005 Jan 05
1
Standalone Mathlib, C++ and ISNAN()
In the hope of some meaningful response and ignoring the risk of
further abuse, let me try to clarify the issue here.
I have re-read the 'Writing R Extensions' manual. It seems to me that
it clearly says R API functions can be called from from C++ programs,
and the API includes the special values ISNAN() and R_FINITE() and the
missing test ISNA().
R_FINITE is no problem. It is
2004 Sep 16
1
[LLVMdev] Patch to lib/System/Interix
Hi
Interix does not know MAP_ANON or -NOCORE only MAP_SHARED, -PRIVATE and
-FIXED.
Henrik
_________________________________________________________________
F� alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Memory.cpp.zip
Type: application/x-zip-compressed
Size: 495 bytes
Desc: not
2004 Sep 14
0
[LLVMdev] Files to lib/System/Win32
>From: Reid Spencer <reid at x10sys.com>
>Date: Mon, 13 Sep 2004 21:07:16 -0700
>
>Henrik,
>
>The patches you submitted will not work (at all) for the Win32 platform
>because they (still) use Unix system calls. Win32 doesn't have mkdtemp,
>fork, execve, etc. Furthermore in Path.cpp forward slashes are still
>used. These need to be changed to back slashes.
>
2004 Aug 31
0
[LLVMdev] Type uint64_t required but not found
Reid,
>Well, if it doesn't break anything else, I'd fix the header file. The
>standard type name is supposed to uint64_t not u_int64_t. I would just
>change the header file to define both of them, something like:
>
>typedef u_int64_t uint64_t;
>
>You could do that in /usr/include/types.h,
I've tried it and it doesn't break anything, but ...
>or we could