[Rd] Wrong config check for __libc_stack_end

[Alba Pompeo]

But it looks like R is working. I found the R binary on build/bin/R
I ran it and it works.
Should I be worried about the make check log?

@Isaac Dunham
Can you please test this on your system too?
Maybe R can be packaged soon?

Ciao.


On Mon, Feb 1, 2016 at 3:33 PM, Alba Pompeo <albapompeo at gmail.com> wrote:
> Here's what I did.
>
> svn checkout https://svn.r-project.org/R/trunk/
> cd ./trunk
> aclocal -I m4 && autoconf
> tools/rsync-recommended
> cd ..
> mkdir build
> cd build
> ../trunk/configure
> make
> make check
>
> On make check it gives an error.
> Here's the log.
> http://pastebin.com/raw/1qfjqQY2
>
>
> On Mon, Feb 1, 2016 at 1:53 PM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>>
>> On Feb 1, 2016, at 9:56 AM, Alba Pompeo <albapompeo at gmail.com> wrote:
>>
>>> @Simon. Here's what I did.
>>> I checked out R revision 70059.
>>> Ran export r_cv_libc_stack_end=no. (otherwise it would give that error
>>> we talked about before)
>>
>> No, the whole point was to test this behavior. I see that the fix is in configure.ac but not configure so you'll need to run something like
>> aclocal -I m4 && autoconf
>> to update it.
>>
>> Also please don't build in the sources - you'll have trouble making sure they are clean. It is recommended to build in a separate directory (see the docs).
>>
>>
>>> Ran ./configure --without-recommended-packages. (otherwise it would
>>> complain of not finding ./src/library/Recommended/MASS_*.tar.gz)
>>
>> I guess you forgot to run
>> tools/rsync-recommended
>> perhaps? It doesn't matter either way for the above issues, but it's probably better to build with recommended packages.
>>
>> Cheers,
>> Simon
>>
>>
>>> Ran make.
>>> Ran make check. Log is here - http://pastebin.com/raw/cGJgqB8p
>>>
>>> What do you think? Is there anything else I can do to help solve this issue?
>>>
>>>
>>>
>>> On Mon, Feb 1, 2016 at 11:36 AM, Simon Urbanek
>>> <simon.urbanek at r-project.org> wrote:
>>>>
>>>> On Feb 1, 2016, at 4:16 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote:
>>>>
>>>>>>>>>> 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.
>>>>>
>>>>
>>>> Agreed, since there is actually no abuse, case was easily dismissed as bogus given the subject.
>>>>
>>>>
>>>>>> 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.
>>>>>
>>>>
>>>> @Alba, can you, please, check that your hypothesis actually holds true and the latest R from trunk fixes the check for you?
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> No, it's actually very crucial as it is used to detect stack overflows.
>>>>
>>>> Cheers,
>>>> Simon
>>>>
>>>>
>>>>
>>>>>>> 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
>>>>>
>>>>> ______________________________________________
>>>>> R-devel at r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>
>>>>
>>>
>>