I tried to build R-2.14.0 on cygwin using the commands: ./configure --with-x=no make I started to get a whole lot of errors starting with: /cygdrive/c/Users/mcarter/src/R-2.14.0/src/modules/internet/Rhttpd.c:275: undefined reference to `_R_InputHandlers' which I have pasted at http://pastebin.com/GFb2pq92 I'm aware that there is a cygwinports ports, but it seems outdated, and when I tried installing it, it was very lengthy and seemed more trouble that it was worth. I abandoned the installation attempt. Any tips on a way forward?
cygwin R-2.14.0 build fail
13 messages · Mark Carter, Peter Dalgaard, Brian Ripley +2 more
On Nov 12, 2011, at 15:25 , Mark Carter wrote:
I tried to build R-2.14.0 on cygwin using the commands: ./configure --with-x=no make I started to get a whole lot of errors starting with: /cygdrive/c/Users/mcarter/src/R-2.14.0/src/modules/internet/Rhttpd.c:275: undefined reference to `_R_InputHandlers' which I have pasted at http://pastebin.com/GFb2pq92 I'm aware that there is a cygwinports ports, but it seems outdated, and when I tried installing it, it was very lengthy and seemed more trouble that it was worth. I abandoned the installation attempt. Any tips on a way forward?
As far as I can tell, what is happening to you is that cygwin needs special configuration to build .dll libraries and ./configure does not know how to set that up. R is not officially supported under Cygwin. Basically, we - er, Brian, mostly, I think - tried it several years ago, and it broke so many times that patience ran out. Others seem to be having better luck with recent versions (Google finds something that looks like ports of 2.13.2, so you might just need a little patience to get 2.14.0), but I think you're altogether better off over on https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
On 12.11.2011 21:28, peter dalgaard wrote:
On Nov 12, 2011, at 15:25 , Mark Carter wrote:
I tried to build R-2.14.0 on cygwin using the commands: ./configure --with-x=no make I started to get a whole lot of errors starting with: /cygdrive/c/Users/mcarter/src/R-2.14.0/src/modules/internet/Rhttpd.c:275: undefined reference to `_R_InputHandlers' which I have pasted at http://pastebin.com/GFb2pq92 I'm aware that there is a cygwinports ports, but it seems outdated, and when I tried installing it, it was very lengthy and seemed more trouble that it was worth. I abandoned the installation attempt. Any tips on a way forward?
As far as I can tell, what is happening to you is that cygwin needs special configuration to build .dll libraries and ./configure does not know how to set that up. R is not officially supported under Cygwin. Basically, we - er, Brian, mostly, I think - tried it several years ago, and it broke so many times that patience ran out. Others seem to be having better luck with recent versions (Google finds something that looks like ports of 2.13.2, so you might just need a little patience to get 2.14.0), but I think you're altogether better off over on https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
Or much simpler: use the native version. Uwe Ligges
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On Sat, 12 Nov 2011, peter dalgaard wrote:
On Nov 12, 2011, at 15:25 , Mark Carter wrote:
I tried to build R-2.14.0 on cygwin using the commands: ./configure --with-x=no make I started to get a whole lot of errors starting with: /cygdrive/c/Users/mcarter/src/R-2.14.0/src/modules/internet/Rhttpd.c:275: undefined reference to `_R_InputHandlers' which I have pasted at http://pastebin.com/GFb2pq92 I'm aware that there is a cygwinports ports, but it seems outdated, and when I tried installing it, it was very lengthy and seemed more trouble that it was worth. I abandoned the installation attempt. Any tips on a way forward?
As far as I can tell, what is happening to you is that cygwin needs special configuration to build .dll libraries and ./configure does not know how to set that up.
It does. Currently R can be built under Cygwin, and how to do so is documented in the R-admin manual. But that was not the case a few weeks ago, so you need to look in R-patched/R-devel (and Cygwin might change again ...).
R is not officially supported under Cygwin. Basically, we - er, Brian, mostly, I think - tried it several years ago, and it broke so many times that patience ran out.
It was broken from most of 2011 too, for three separate reasons. Even when it 'works', it is far slower than the native Windows port and it fails 'make check' (not handling CR-delimited files, problems with wide-characters as Cygwin does not have proper locales).
Others seem to be having better luck with recent versions (Google finds something that looks like ports of 2.13.2, so you might just need a little patience to get 2.14.0), but I think you're altogether better off over on https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
-- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
3 days later
On 11/12/2011 3:25 PM, Mark Carter wrote:
I tried to build R-2.14.0 on cygwin using the commands: ./configure --with-x=no make I started to get a whole lot of errors starting with: /cygdrive/c/Users/mcarter/src/R-2.14.0/src/modules/internet/Rhttpd.c:275: undefined reference to `_R_InputHandlers' which I have pasted at http://pastebin.com/GFb2pq92 I'm aware that there is a cygwinports ports, but it seems outdated, and when I tried installing it, it was very lengthy and seemed more trouble that it was worth. I abandoned the installation attempt. Any tips on a way forward?
just built R-2.14.0 deriving from R-2.13.1-1 of cygport.
configure --with-blas="$(pkg-config --libs blas)" \
--with-lapack \
--enable-R-shlib \
TCLTK_LIBS="-ltcl84 -ltk84" \
--with-system-zlib \
--with-system-bzlib \
--with-system-pcre \
--with-system-xz \
--disable-openmp
almost all test passed
$ grep OK R-2.14.0-1-check.log |wc -l
57
only 3 minor failures
$ find ../build/ -name *fail
../build/tests/Examples/parallel-Ex.Rout.fail
../build/tests/reg-BLAS.Rout.fail
../build/tests/reg-IO.Rout.fail
If you are interested I can provide you the binary package.
Regards
Marco
The failures are *not* minor. Please don't distribute an R linked to a broken BLAS library. Those tests are not for fun: they came from real errors on real problems.
On Wed, 16 Nov 2011, marco atzeri wrote:
On 11/12/2011 3:25 PM, Mark Carter wrote:
I tried to build R-2.14.0 on cygwin using the commands: ./configure --with-x=no make I started to get a whole lot of errors starting with: /cygdrive/c/Users/mcarter/src/R-2.14.0/src/modules/internet/Rhttpd.c:275: undefined reference to `_R_InputHandlers' which I have pasted at http://pastebin.com/GFb2pq92 I'm aware that there is a cygwinports ports, but it seems outdated, and when I tried installing it, it was very lengthy and seemed more trouble that it was worth. I abandoned the installation attempt. Any tips on a way forward?
just built R-2.14.0 deriving from R-2.13.1-1 of cygport.
configure --with-blas="$(pkg-config --libs blas)" \
--with-lapack \
--enable-R-shlib \
TCLTK_LIBS="-ltcl84 -ltk84" \
--with-system-zlib \
--with-system-bzlib \
--with-system-pcre \
--with-system-xz \
--disable-openmp
almost all test passed
$ grep OK R-2.14.0-1-check.log |wc -l
57
only 3 minor failures
$ find ../build/ -name *fail
../build/tests/Examples/parallel-Ex.Rout.fail
../build/tests/reg-BLAS.Rout.fail
../build/tests/reg-IO.Rout.fail
If you are interested I can provide you the binary package.
Regards
Marco
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
On 11/16/2011 9:32 PM, Prof Brian Ripley wrote:
The failures are *not* minor. Please don't distribute an R linked to a broken BLAS library. Those tests are not for fun: they came from real errors on real problems.
Dear Brian,
I am reasonable sure that the cygwin blas library are fine, have
you any evidence that they are broken ?
The R test log just reports an issue handling NA that could be
related to cygwin difference to others platform.
I already noted similar difference on cygwin octave package.
Here is the log:
--------------------------------------------------
> ## PR#4582 %*% with NAs
> stopifnot(is.na(NA %*% 0), is.na(0 %*% NA))
> ## depended on the BLAS in use.
>
>
> ## found from fallback test in slam 0.1-15
> ## most likely indicates an inaedquate BLAS.
> x <- matrix(c(1, 0, NA, 1), 2, 2)
> y <- matrix(c(1, 0, 0, 2, 1, 0), 3, 2)
> (z <- tcrossprod(x, y))
[,1] [,2] [,3]
[1,] NA NA 0
[2,] 2 1 0
> stopifnot(identical(z, x %*% t(y)))
Error: identical(z, x %*% t(y)) is not TRUE
Execution halted
tests/reg-BLAS.Rout.fail (END)
--------------------------------------------------
Regards
Marco
On Nov 16, 2011, at 22:08 , marco atzeri wrote:
On 11/16/2011 9:32 PM, Prof Brian Ripley wrote:
The failures are *not* minor. Please don't distribute an R linked to a broken BLAS library. Those tests are not for fun: they came from real errors on real problems.
Dear Brian, I am reasonable sure that the cygwin blas library are fine, have you any evidence that they are broken ? The R test log just reports an issue handling NA that could be related to cygwin difference to others platform. I already noted similar difference on cygwin octave package.
Well, on other platforms we have
tcrossprod(x,y)
[,1] [,2] [,3] [1,] NA NA NA [2,] 2 1 0
x %*% t(y)
[,1] [,2] [,3] [1,] NA NA NA [2,] 2 1 0 so the Cygwin tcrossprod is implicitly letting 0*NA==0 (in the DGEMM BLAS routine). This is not what should happen according to the standards, and there are people whose code relies on standards compliance (and that's why the test is there). It's also plain wrong, because in extended arithmetic, the missing value could be Inf, and 0*Inf == NaN, so assuming that 0*anything==0 doesn't work. -pd
Here is the log: --------------------------------------------------
## PR#4582 %*% with NAs stopifnot(is.na(NA %*% 0), is.na(0 %*% NA)) ## depended on the BLAS in use. ## found from fallback test in slam 0.1-15 ## most likely indicates an inaedquate BLAS. x <- matrix(c(1, 0, NA, 1), 2, 2) y <- matrix(c(1, 0, 0, 2, 1, 0), 3, 2) (z <- tcrossprod(x, y))
[,1] [,2] [,3] [1,] NA NA 0 [2,] 2 1 0
stopifnot(identical(z, x %*% t(y)))
Error: identical(z, x %*% t(y)) is not TRUE Execution halted tests/reg-BLAS.Rout.fail (END) -------------------------------------------------- Regards Marco
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
On 11/16/2011 11:04 PM, peter dalgaard wrote:
On Nov 16, 2011, at 22:08 , marco atzeri wrote:
On 11/16/2011 9:32 PM, Prof Brian Ripley wrote:
The failures are *not* minor. Please don't distribute an R linked to a broken BLAS library. Those tests are not for fun: they came from real errors on real problems.
Dear Brian, I am reasonable sure that the cygwin blas library are fine, have you any evidence that they are broken ? The R test log just reports an issue handling NA that could be related to cygwin difference to others platform. I already noted similar difference on cygwin octave package.
Well, on other platforms we have
tcrossprod(x,y)
[,1] [,2] [,3] [1,] NA NA NA [2,] 2 1 0
x %*% t(y)
[,1] [,2] [,3] [1,] NA NA NA [2,] 2 1 0 so the Cygwin tcrossprod is implicitly letting 0*NA==0 (in the DGEMM BLAS routine). This is not what should happen according to the standards, and there are people whose code relies on standards compliance (and that's why the test is there). It's also plain wrong, because in extended arithmetic, the missing value could be Inf, and 0*Inf == NaN, so assuming that 0*anything==0 doesn't work. -pd
I presume it is a netlib DGEMM issue and not a specific cygwin port issue. There is an optimization on the reference implementation: http://www.netlib.org/lapack/explore-html/d7/d2b/dgemm_8f_source.html 00314 IF (B(L,J).NE.ZERO) THEN that fool any 0*NaN or 0*Inf case I noticed it was highlighted on octave mailing list long time ago: http://octave.1599824.n4.nabble.com/NaN-problem-td1662846.html Time to rise the bug with netlib guys ? Regards Marco
On 17.11.2011 00:34, marco atzeri wrote:
On 11/16/2011 11:04 PM, peter dalgaard wrote:
On Nov 16, 2011, at 22:08 , marco atzeri wrote:
On 11/16/2011 9:32 PM, Prof Brian Ripley wrote:
The failures are *not* minor. Please don't distribute an R linked to a broken BLAS library. Those tests are not for fun: they came from real errors on real problems.
Dear Brian, I am reasonable sure that the cygwin blas library are fine, have you any evidence that they are broken ? The R test log just reports an issue handling NA that could be related to cygwin difference to others platform. I already noted similar difference on cygwin octave package.
Well, on other platforms we have
tcrossprod(x,y)
[,1] [,2] [,3] [1,] NA NA NA [2,] 2 1 0
x %*% t(y)
[,1] [,2] [,3] [1,] NA NA NA [2,] 2 1 0 so the Cygwin tcrossprod is implicitly letting 0*NA==0 (in the DGEMM BLAS routine). This is not what should happen according to the standards, and there are people whose code relies on standards compliance (and that's why the test is there). It's also plain wrong, because in extended arithmetic, the missing value could be Inf, and 0*Inf == NaN, so assuming that 0*anything==0 doesn't work. -pd
I presume it is a netlib DGEMM issue and not a specific cygwin port issue. There is an optimization on the reference implementation: http://www.netlib.org/lapack/explore-html/d7/d2b/dgemm_8f_source.html 00314 IF (B(L,J).NE.ZERO) THEN that fool any 0*NaN or 0*Inf case I noticed it was highlighted on octave mailing list long time ago: http://octave.1599824.n4.nabble.com/NaN-problem-td1662846.html Time to rise the bug with netlib guys ?
Everybody in this discussion invested too much time on it already. If you want to provide cygwin support for others, go ahead and tackle the problems, but don't distribute incorrectly working versions of R. Best, Uwe Ligges
Regards Marco
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On 11/17/2011 10:11 AM, Uwe Ligges wrote:
Everybody in this discussion invested too much time on it already. If you want to provide cygwin support for others, go ahead and tackle the problems, but don't distribute incorrectly working versions of R.
Dear Uwe, first test versions are always by definition incorrectly working versions. Reading http://cran.r-project.org/doc/manuals/R-admin.html#BLAS http://cran.r-project.org/doc/manuals/R-admin.html#LAPACK it is clear that R relies with its internal BLAS and Lapack implementation, differently from a lot of other packages. May I suggest to add an additional note that also external BLAS is not recommended as done for LAPACK. It will be also worth to add a "not recommended" on the configure --help output --with-blas use system BLAS library (if available), or specify it [no] --with-lapack use system LAPACK library (if available), or specify it [no] as it is not obvious and it could mislead newcomers like me.
Best, Uwe Ligges
Best Regards Marco
On 17.11.2011 12:33, marco atzeri wrote:
On 11/17/2011 10:11 AM, Uwe Ligges wrote:
Everybody in this discussion invested too much time on it already. If you want to provide cygwin support for others, go ahead and tackle the problems, but don't distribute incorrectly working versions of R.
Dear Uwe, first test versions are always by definition incorrectly working versions. Reading http://cran.r-project.org/doc/manuals/R-admin.html#BLAS http://cran.r-project.org/doc/manuals/R-admin.html#LAPACK it is clear that R relies with its internal BLAS and Lapack implementation, differently from a lot of other packages. May I suggest to add an additional note that also external BLAS is not recommended as done for LAPACK. It will be also worth to add a "not recommended" on the configure --help output --with-blas use system BLAS library (if available), or specify it [no] --with-lapack use system LAPACK library (if available), or specify it [no] as it is not obvious and it could mislead newcomers like me.
External BLASs work for me perfectly on other platforms than cygwin. Hence it is cygwin that I would not recommend given the native Windows version is both faster and passes the checks. Uwe Ligges
Best, Uwe Ligges
Best Regards Marco
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On 11/17/2011 2:12 PM, Uwe Ligges wrote:
External BLASs work for me perfectly on other platforms than cygwin. Hence it is cygwin that I would not recommend given the native Windows version is both faster and passes the checks. Uwe Ligges
Yeah, I am almost sure that your view as R developer and mine as package maintainer for several math packages in cygwin do not match. If speed was the only parameter for a solution choice , we should all only use Linux for math and Windows for games. From http://bugs.r-project.org/bugzilla3/show_bug.cgi?id=4582 it is clear that R expectation from a BLAS library is different from the netlib BLAS reference implementation and I presume it happens also on any Linux using the netlib BLAS, so I do not see it as a specific cygwin bug. Regards and Thanks for your time Marco