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
