@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)
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.urba...@r-project.org> wrote:
>
> On Feb 1, 2016, at 4:16 AM, Martin Maechler <maech...@stat.math.ethz.ch> 
> wrote:
>
>>>>>>> Alba Pompeo <albapom...@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
>>> <albapom...@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 <maech...@stat.math.ethz.ch>  http://stat.ethz.ch/people/maechler
>> Seminar für Statistik, ETH Zürich
>>
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to