similar to: Cannot call R's ISNAN() from a C code in >1.7 versions.

Hi guys, I discovered xapian today and I'm trying it because it looks promising compared to other FTS engines. However I'm in a windows environment so it's a bit painful to set up as there is no official binaries. I've heard about http://www.flax.co.uk/xapian_binaries And I'm trying to build their latest release (1.2.8). After a few tries I manage to compile everything with

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]

I have a problem building an extension using ISNAN() on R version 2.0.x. In R 1.9.1 Arith.h and Rmath.h contained code like #ifdef IEEE_754 # define ISNAN(x) (isnan(x)!=0) #else # define ISNAN(x) R_IsNaNorNA(x) #endif #define R_FINITE(x) R_finite(x) int R_IsNaNorNA(double); int R_finite(double); which works. R 2.0.x has # define ISNAN(x) (isnan(x)!=0) unconditionally. This breaks

I have a problem building an extension using ISNAN() on R version 2.0.x. In R 1.9.1 Arith.h and Rmath.h contained code like #ifdef IEEE_754 # define ISNAN(x) (isnan(x)!=0) #else # define ISNAN(x) R_IsNaNorNA(x) #endif #define R_FINITE(x) R_finite(x) int R_IsNaNorNA(double); int R_finite(double); which works. R 2.0.x has # define ISNAN(x) (isnan(x)!=0) unconditionally. This breaks

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]:

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

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, adding a case that checks if the compiler is MSVC instead of adding HAVE_FINITE_IN_FLOAT_H and HAVE_ISNAN_IN_FLOAT_H to the config.h file. I don't know which is the best approach, but this is the minimal patch to make it work... m. --------------

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, >

Hi, I just started with LLVM so I'm not sure who's responsible for portability. Anyways, I found the following problems trying to compile llvm rev 94074 with the solution generated using cmake 2.8 (including the clang front end) on 32bit vista: lib/system Errno.cpp : had to add "#undef HAVE_STRERROR_R" raw_ostream.cpp: had to add "#undef HAVE_UNISTD_H"

Hello, I submitted a package which used Fortran functions isnan and lgamma. However, I was told that: isnan and lgamma are not Fortran 95 functions. I was asked to write 'cross-platform portable code' and so should not be writing GNU extensions to Fortran. See http://cran.r-project.org/web/checks/check_results_mpath.html, which will shortly show installation failures under Solaris. I

Hi, i had the same troubles on Vista and on Win7... cmake fails on some tests (you should see this in the log) due to m$ UAC (or whatever the name is) and uses not-so-sane default values. You have to start a visual c-command prompt (to make sure it gets the right paths) with administrator privileges (!) , than cmake works fine and you get a correct config.h. best regards, Thomas 2010/1/22

I'm having a hell of a time linking against libFLAC_static.lib on Win32: link -out:blib\arch\auto\Audio\FLAC\Decoder\Decoder.dll -dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\Perl\lib\CORE" -machine:x86 Decoder.obj libflacsupport.lib C:\Perl\lib\CORE\perl58.lib C:\Perl\lib\CORE\libFLAC_static.lib -def:Decoder.def Creating library

... Or maybe not? I just tried it again in the exact same configuration that did work before, and this time it fails at an earlier stage with a different error: [ 66%] Building CXX object lib/Target/Mips/CMakeFiles/LLVMMipsCodeGen.dir/Mips16FrameLowering.cpp.obj Mips16FrameLowering.cpp NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~2.0\VC\bin\cl.exe' : return code '0xffffffff'

After some running some more tests, a weird addendum to this case: the build also fails at the same place with the same error message if MinGW isn't in the path. I'm not talking about MinGW instead of Microsoft C++, it's just that the build works if and only if MinGW is in the path _as well as_ the 32-bit version of Microsoft C++. On Sat, Aug 24, 2013 at 8:15 PM, Russell Wallace

I'm trying to build LLVM 3.3 using cmake/nmake, Microsoft C++ 2012, on a 64-bit Windows 7 system. I tried it with the 32-bit compiler as a test case first and that appeared to work, then with the 64-bit compiler in the hope that would give me a 64-bit build of LLVM, but instead got this error message: [ 86%] Generating X86CompilationCallback_Win64.obj Microsoft (R) Macro Assembler (x64)

Hi Brian, I've been playing around with your test programs and came to the result: --------------------- #ifdef __INTERIX # define _GLIBCPP_USE_C99 1 //Define this macro before including isnan() function from cmath #endif #include <cmath> using std::isnan; int foo(float f) {return isnan(f);} --------------------- /Henrik >From: "Brian R. Gaeke" <gaeke at

Hi Russel, I never tried to build LLVM with nmake. With msbuild it works without problems. You can find a short desription here: http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC, section Build LLVM. Regards Kai On 24.08.2013 21:15, Russell Wallace wrote: > I'm trying to build LLVM 3.3 using cmake/nmake, Microsoft C++ 2012, on a > 64-bit Windows 7 system. I

Thanks for your help in adance !!! I work with SAMBA HEAD since alpha24. I have running a BDC, PDC, Printserver on 3 separate pc's. In my domain is integrated a nativ w2k Fileserver ( Dell Nas PowerVault 725 ) for fileserving. Passwords are held in LDAP on every (Linux) machine pam-ldap works. Every thing was fine before the last update to BETA 3. Problem : I was updating from BETA 2 to

On Thu, Nov 8, 2018 at 11:35 PM Fabian Giesen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > What is so complicated about these? Shouldn't they just correspond to > two compares + selects? > > To give a concrete example, x86 MIN[SP][SD] and MAX[SP][SD], > respectively, correspond exactly to > > MIN*: select(a < b, a, b) (i.e. "a < b ? a : b")

I've followed all the LLVM+clang build-from-source instructions for Windows using MSVC++ 2008. It all builds fine. I initially had troubling getting any linking to work at all until I made sure to have the right environment variables set using a wrapper batch script. Now C programs compile, link, and execute fine, but C++ programs don't link, not even a simple "hello, world"