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 <albapom...@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.urba...@r-project.org> wrote: >> >> On Feb 1, 2016, at 9:56 AM, Alba Pompeo <albapom...@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.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
