similar to: [LLVMdev] IsNAN.cpp:23:3: #error "Don't know how to get isnan()"

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