>>>>> 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. > 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. 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 <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