@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 >> >
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 point was that you use a clean checkout (do NOT build in the sources) and don't override anything ..> 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 >>> >> >
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 >>> >> >
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 >>>> >>> >> >