[Rd] Wrong config check for __libc_stack_end

[Martin Maechler]

>>>>> Alba Pompeo <albapompeo at gmail.com>
>>>>>     on Fri, 29 Jan 2016 08:23:26 -0200 writes:

    > Here is my log from 'make check' using an Intel i5 64-bit
    > processor - http://pastebin.com/raw/N6SYAuFX Here is
    > Isaac's log from 'make check' using an Intel Atom 32-bit
    > processor - http://pastebin.com/raw/sey6DEk9

    > We are both on Alpine Linux, which uses the musl
    > libc. http://www.musl-libc.org/

    > Thank you very much.

It probably would have helped to choose a different subject
which I now do.

    > On Thu, Jan 28, 2016 at 9:54 AM, Alba Pompeo
    > <albapompeo at gmail.com> wrote:
    >> Hello, developers of R.
    >> 
    >> I have been unsuccessfully trying to build R on a musl
    >> libc system for the last days.  ./configure works, but
    >> make fails. The command that errors out is here -
    >> http://pastebin.com/raw/UwFRsiqT
    >> 
    >> It was brought to my attention that this is a (very
    >> longstanding) abuse of a private glibc symbol in R.
    >> 
    >> In R 3.2.3, it seems that configure is trying to test for
    >> it on Linux.  It apparently fails to accurately test (as
    >> demonstrated by the link error), perhaps because the test
    >> program does not actually *use* __libc_stack_end so it
    >> gets optimized out. (See line 35500 or so in
    >> R-3.2.3/configure.)  Ideally, the test program would
    >> check that a pointer to __libc_stack_end is non-null, but
    >> that's an autoconf bug.

So, ideally someone who knows autoconf much better than I do
should submit a bug report to the autoconf maintainers.

Back to R: I'm not familiar with that part of the code, neither
the configuration, nor the usage (in  R/src/unix/system.c ).
However, that code seems to be using a a glibc "feature" widely
available which does help making R startup (a very tiny bit ??)
faster.

    >> A work around was to 'export r_cv_libc_stack_end=no'
    >> before configuring R.  

which *does* solve that problem, right?

    >> However, there are a couple little issues with non-ASCII
    >> text and a *lot* of math differences, many of which say
    >> "*no* convergence: NOTIFY R-core!".

Hmm, I may be off, but these would look like entirely unrelated
with the libc_stack_end availibility, wouldn't they ?

Maybe you / the musl developers should try to make those C
libraries more "standard", notably because I would see math
differences as something pretty grave for R, and indeed, I would
not want to use a platform where R's math functions work
incompatibly with all other platforms ... but maybe I
misunderstand completely.

Hmm... I've found this,

http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Floating-point_and_mathematical_library

which make what you say above more relevant/interesting.

Still, from this thread I get that the C source code of R needs
considerable configuration patches before R can work with musl.
But that needs another thread, something like  'Building R with musl'.

    >> Until these are resolved, R can't be packaged for
    >> distributions that use musl, such as Alpine Linux.

which I agree would not be ideal.
Martin

--
Martin <Maechler at stat.math.ethz.ch>  http://stat.ethz.ch/people/maechler
Seminar für Statistik, ETH Zürich