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 >>>> >>> >> >
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 >>>>> >>>> >>> >>
Martin Maechler
2016-Feb-01 17:49 UTC
[Rd] More problems with building R on a musl platform
>>>>> Alba Pompeo <albapompeo at gmail.com> >>>>> on Mon, 1 Feb 2016 15:33:11 -0200 writes:> 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 Thank you. It shows some output differences for complex arithmetic, which *may* be a bad sign for the musl routines, or the (also alternative ??) math lib you have on your platform. But these differences where not leading to the failure, rather is the reason close to the end of the log: ------------------------------------------------ make[3]: *** [reg-tests-1c.Rout] Error 1 ------------------------------------------------ and these are the very latest regression checks, so they should not fail. If you want, you can also make the tests/reg-tests-1c.Rout.fail file available via a link above, but to me, it currently looks there needs to be a bit more work on your system libraries (or possibly on our configuration) side before you should bundle R with your Alpine Linux. I'd call it "unsafe" for now. Martin -- Martin Maechler, ETH Zurich and R Core Team. >>>> 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: [.........] >>>>>>> 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
Here is tests/reg-tests-1c.Rout.fail - http://pastebin.com/raw/3QVDUBwT About the libm, I don't know which one R uses. musl has its on libm. http://git.musl-libc.org/cgit/musl/tree/src/math I think I also have openlibm installed, but I don't think that's used. Any more information I can give to help debug this? Thanks. On Mon, Feb 1, 2016 at 3:49 PM, Martin Maechler <maechler at stat.math.ethz.ch> wrote:>>>>>> Alba Pompeo <albapompeo at gmail.com> >>>>>> on Mon, 1 Feb 2016 15:33:11 -0200 writes: > > > 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 > > Thank you. It shows some output differences for complex > arithmetic, which *may* be a bad sign for the musl routines, or > the (also alternative ??) math lib you have on your platform. > But these differences where not leading to the failure, > rather is the reason close to the end of the log: > ------------------------------------------------ > make[3]: *** [reg-tests-1c.Rout] Error 1 > ------------------------------------------------ > > and these are the very latest regression checks, so they should not fail. > If you want, you can also make the > tests/reg-tests-1c.Rout.fail > > file available via a link above, > but to me, it currently looks there needs to be a bit more work > on your system libraries (or possibly on our configuration) side > before you should bundle R with your Alpine Linux. > > I'd call it "unsafe" for now. > Martin > > -- > Martin Maechler, ETH Zurich and R Core Team. > > >>>> 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: > > [.........] > > >>>>>>> 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