>>>>> 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. > 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. 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. >> 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
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 >
@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.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 >> >
>>>>> Simon Urbanek <simon.urbanek at r-project.org> >>>>> on Mon, 1 Feb 2016 08:36:56 -0500 writes:> On Feb 1, 2016, at 4:16 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: [..............] >> 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 Well, I think you misunderstood what I meant to say (or then I'm happy for clarification if I misunderstood you) : The #ifdef ... #elseif ... #else ... # endif branch which *uses* the __libc_stack_end "variable" would hopefully be a speedup in comparison with the alternatives; from system.c mentioned above: #if defined(HAVE_LIBC_STACK_END) R_CStackStart = (uintptr_t) __libc_stack_end; #elif defined(HAVE_KERN_USRSTACK) { /* Borrowed from mzscheme/gc/os_dep.c */ int nm[2] = {CTL_KERN, KERN_USRSTACK}; void * base; size_t len = sizeof(void *); (void) sysctl(nm, 2, &base, &len, NULL, 0); R_CStackStart = (uintptr_t) base; } #else if(R_running_as_main_program) { /* This is not the main program, but unless embedded it is near the top, 5540 bytes away when checked. */ R_CStackStart = (uintptr_t) &i + (6000 * R_CStackDir); } #endif if(R_CStackStart == -1) R_CStackLimit = -1; /* never set */ /* printf("stack limit %ld, start %lx dir %d \n", R_CStackLimit, R_CStackStart, R_CStackDir); */ } #endif so I'd hope that typically R_CStackStart would be set usefully also when the __libc_stack_end is not available. If not, that would mean that for the 'musl' lovers, R would not be able to detect stack overflows.... which would probably be quite undesirable.