similar to: latest beta + MinGW 3.1.0-1 = minor fix needed

Problem: Build of R failed when compiling sockconn.c. The problem seemed to be that ssize_t was not defined. The following change in sock.h fixes the problem, though it's probably not fixed the _right_ way. /* Following line changed by WTR (Cira) to overcome make problem. #if defined Win32 && !defined _SSIZE_T_ typedef int ssize_t; #endif */ typedef int ssize_t; Thanks! Wade

> The main idea of llvm-gcc is to be a drop-in replacement of gcc. So, > if you know how to install & run gcc on your system, you should be > able to do the same with llvm-gcc (thus no "Getting Started" entry). > Basically the only "packaging differences" wrt normal gcc is that > we're shipping w32api & mingw-runtime packages with llvm-gcc. Surely,

Hello, Jon The main idea of llvm-gcc is to be a drop-in replacement of gcc. So, if you know how to install & run gcc on your system, you should be able to do the same with llvm-gcc (thus no "Getting Started" entry). Basically the only "packaging differences" wrt normal gcc is that we're shipping w32api & mingw-runtime packages with llvm-gcc. Surely, you still need

Hello, Jon > What threw me was the projects inclusion of 2 of the 3 other pieces that make up a typical manual install of mingw or http://www.tdragon.net/recentgcc/  I saw the runtime and w32api stuff in my very quick scan of the llvm-gcc dir and didn't bother to confirm binutils :( Well, binutils are quite different: 1. It's GPL-licensed, thus we need to provide sources as well, which

I've just got flac-1.0.4 to successfully compile under my MinGW environment: MinGW-2.0.0-3 - binutils-2.13.90-20021006-2 - w32api-2.1 MSYS-1.0.8-rc4 This is on an AMD Athlon machine with 512MB RAM running Windows XP. The only change I had to make was to include/FLAC/ordinals.h.in to remove the reference to MINGW32 on line 39 - without this change the compile bailed out very early on.

Hello, Everyone. I'm currently trying to bootstrap llvm-gcc4 on mingw32 platform. Everything (except some small fixes) seems to be fine: stage1 finished successfully. I'm linking with debug variant of LLVM, since linker bug prevents release builds. Unfortunately, stage2 failes immediately with this cryptic message: $/f/tmp/llvm/gccbuild/gcc/xgcc -B/f/tmp/llvm/gccbuild/gcc/

Hi, after changing mksh to no longer use mkstemp, I decided to try and build mksh-static with klcc on most platforms, in Debian. Here are the results by Debian architecture: alpha (4) fails amd64 works armel works armhf (3) fails i386 works ia64 works m68k (1) workaround mips works mipsel works powerpc (2) fails ppc64 works (!) s390 works s390x works sparc works Architectures not listed either

Not sure if that's related, but we had two failures last night as well: MacOS/Universal build failed on rev 54197, when building the x86->ppc cross: cc1: warnings being treated as errors /Users/julien/buildbot/llvm/gcc-build/src/gcc/cp/pt.c:5296: warning: no previous prototype for 'outermost_tinst_level' make[2]: *** [cp/pt.o] Error 1 MingW failed on rev 54208:

So the fundamental problem I'm trying to solve is how get my cfrontend build configured properly. The usual symptom of an incorrect configuration is the inability to find various header files. Here's some example spew: $ /home/llvm_home/llvm-gcc-build/gcc/xgcc -v -B/home/llvm_home/llvm-gcc-build/gcc/ -Bc:/msys/1.0/mingw32/bin/ -Bc:/msys/1.0/mingw32/lib/ -isystem

Hi, I don't seem to be able to solve this regression with llvm-gcc-4.2 on Cygwin. It is weird as I thought I had checked SVN TOT and had a good build just before the branch was corrected, so am confused. If someone more experienced with debugging could have a look at this, its like a syntax error. I have tried whittling the error down but it just moves. Trying to bisect between r98185 and

I've blown a couple of weekends trying to build under MinGW. I can build the llvm tools with only a couple of minor hassles, but can't seem to make any headway with the C Front End Most errors I run into involve not being able to find header files. The most frustrating part is that the error messages report that the file can't be found, and then proceed to give a path to where the

Hi, I have got GCC 3.4.3 and binutils 2.15 installed on Cygwin. Had to copy as.exe to gccas.exe to get llvm-gcc to get this far. I am getting the following error message(s) :- /usr/build/llvm-gcc/gcc/xgcc -B/usr/build/llvm-gcc/gcc/ -B/usr/llvm-gcc/i686-pc- cygwin/bin/ -B/usr/llvm-gcc/i686-pc-cygwin/lib/ -isystem /usr/llvm-gcc/i686-pc-c ygwin/include -isystem

Hi, I don't know if I'm sending this to the right place but I've looked throught tens and tens of topics on http://tolstoy.newcastle.edu.au/ and finally found that email address where I can maybe find some help. Well my main goal is to get to use the lapack library within my R package (which can be done using calls from C). But in order to do this I have to create a file src/Makevars

Hi, I don't know if I'm sending this to the right place but I've looked throught tens and tens of topics on http://tolstoy.newcastle.edu.au/ and finally found that email address where I can maybe find some help. Well my main goal is to get to use the lapack library within my R package (which can be done using calls from C). But in order to do this I have to create a file src/Makevars

Building R 2.3.0 fails under Red Hat 9.0 because ssize_t is not defined in src/modules/internet/sock.h. Inserting #include <sys/types.h> at the top of this file fixes the problem.

Hi, I?ve gone through the mailing list archives and hereby want to resubmit my pending patches. Most are independent of each other, except the m68k patch which will only be complete if sigsuspend is also fixed. (It can be applied before that, though.) http://www.zytor.com/pipermail/klibc/2012-January/003173.html [PATCH] fix m68k support Resubmitted here as 0005. While there was a question from

Hello, Greg. You wrote Sunday, May 7, 2006, 10:46:34 PM: GP> 3. One potential point of control is the INCLUDES variable found in GP> cfrontent/gcc/Makefile.in: GP> INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ GP> -I$(srcdir)/../include @INCINTL@ Just unpack mingw32's headers & libs (w32api && mingw-runtime) into prefix directory. And configure script

On Dec 16, 2009, at 8:34 AM, Anton Korobeynikov wrote: > Hello, Jon > >> What threw me was the projects inclusion of 2 of the 3 other pieces >> that make up a typical manual install of mingw or http://www.tdragon.net/recentgcc/ >> I saw the runtime and w32api stuff in my very quick scan of the >> llvm-gcc dir and didn't bother to confirm binutils :( >

> > What threw me was the projects inclusion of 2 of the 3 other pieces that make up a typical manual install of mingw or http://www.tdragon.net/recentgcc/  I saw the runtime and w32api stuff in my very quick scan of the llvm-gcc dir and didn't bother to confirm binutils :( > Well, binutils are quite different: > 1. It's GPL-licensed, thus we need to provide sources as well,

Hello! I'm not sure if this is the right place to post this, so apologies in advance if I'm not in the right list. I downloaded the OpenBLAS and am following Avraham Adler's great instructions. However, when I run make, things go well to a certain point, and then go bad: make [snip] touch cygopenblas_haswellp-r0.3.5.a make -j 1 -C test all make[1]: Entering directory