search for: libc_stack_end

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

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

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

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

...gt;>>> 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 gra...

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

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

...ght 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. A work around was to 'export r_cv_libc_stack_end=no' before configuring R. However, there are a coupl...