FAQ
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?

Search Discussions

  • Peter dalgaard at Nov 12, 2011 at 8:28 pm

    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
  • Uwe Ligges at Nov 12, 2011 at 8:51 pm

    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
  • Prof Brian Ripley at Nov 13, 2011 at 7:37 am
    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
  • Marco atzeri at Nov 16, 2011 at 3:11 pm

    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
  • Prof Brian Ripley at Nov 16, 2011 at 8:32 pm
    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
  • Marco atzeri at Nov 16, 2011 at 9:08 pm

    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
  • Peter dalgaard at Nov 16, 2011 at 10:04 pm

    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
  • Marco atzeri at Nov 16, 2011 at 11:34 pm

    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
  • Uwe Ligges at Nov 17, 2011 at 9:11 am

    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
  • Marco atzeri at Nov 17, 2011 at 11:33 am

    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
  • Uwe Ligges at Nov 17, 2011 at 1:12 pm

    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
  • Marco atzeri at Nov 17, 2011 at 2:53 pm

    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?idE82

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupr-devel @
categoriesr
postedNov 12, '11 at 2:25p
activeNov 17, '11 at 2:53p
posts13
users5
websiter-project.org
irc#r

People

Translate

site design / logo © 2022 Grokbase