[Rd] Wrong config check for __libc_stack_end

[Simon Urbanek]

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
>