From simon.urbanek at r-project.org  Mon Feb  1 16:45:09 2016
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Mon, 1 Feb 2016 10:45:09 -0500
Subject: [Rd] Wrong config check for __libc_stack_end
In-Reply-To: <CAJDAfTBqWuG53=a8ei63ZFmCjXzTFJ6kQmKG7c20f5zqiHoRyw@mail.gmail.com>
References: <CAJDAfTBZ5FNAsPuoRyk6CLEOPKG-JpY4OoQ3On-brcHS6UnafA@mail.gmail.com>
	<CAJDAfTAC1U92DXWvxkx7U9ORtJXtY+_e8i3MT85B3o6MsaEkKA@mail.gmail.com>
	<22191.8837.813670.863210@stat.math.ethz.ch>
	<AB464163-D2A0-41EA-A4B1-74412D55AD47@r-project.org>
	<CAJDAfTBqWuG53=a8ei63ZFmCjXzTFJ6kQmKG7c20f5zqiHoRyw@mail.gmail.com>
Message-ID: <8B548E62-9105-4D2F-A7C0-DC215ECB2DE9@r-project.org>


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 point was that you use a clean checkout (do NOT build in the sources) and don't override anything ..



> Ran ./configure --without-recommended-packages. (otherwise it would
> complain of not finding ./src/library/Recommended/MASS_*.tar.gz)
> 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
>>> 
>> 
> 



[Rd] Wrong config check for __libc_stack_end
Simon Urbanek