[Rd] R uses private function in libc (PR#9107)

[ripley at stats.ox.ac.uk]

On Fri, 28 Jul 2006, Thomas Lumley wrote, quoting someone else:

> > In any case, as you can see, __libc_stack_end goes away completely by libc
> > 2.3.6, 

I don't see this: my FC3 AMD64 *g*libc 2.3.6 system gives

  2148: 00000000     4 OBJECT  GLOBAL DEFAULT  UND 
__libc_stack_end at GLIBC_2.1 (22)
  9516: 00000000     4 OBJECT  GLOBAL DEFAULT  UND 
__libc_stack_end@@GLIBC_2

so the claim is not a general property of glibc 2.3.6.  Indeed, it seems 
rather to be a question of visibility: the symbol has NOT `gone away 
completely' but been hidden in the .so (it is visible in libc.a in vanilla 
glibc 2.4).

It had already been said that many systems using glibc 2.3.6 or 2.4 do 
export the symbol, as evidenced by the RPMs that exist for FC3 (at 2.3.6) 
and FC5 (at 2.4), the runs on the Debian test farm, and the absence of 
reported problems from anywhere else on any Linux system.  (Not only that, 
the code detects C stack overflows at the intended stack size limit, so 
the symbol linked to has the expected value.)

I had checked the glibc Changelogs and found nothing relevant, and it 
seems this is an undocumented change that the major distros have reverted 
and hence not much of a problem.

> > and as noted in the follow-up I sent to this bug yesterday, the
> > reasons one shouldn't use this symbol are quite clearly stated here:
> >
> > <http://www.mail-archive.com/debian-glibc@lists.debian.org/msg28253.html>
> >
> 
> Only up to a point.  We know that __libc_stack_end is not portable, but it 
> is being used to do something that is impossible to do portably: check 
> whether the C stack is about to overflow. Since there is no way to recover 
> from a C stack overflow, being able to prevent it is valuable.
> 
> Your fix disables this facility on all Linux systems, which may be 
> appropriate for your systems but is clearly undesirable as a change to R. 
> The real question is how to detect systems that do provide 
> __libc_stack_end and whether there is another non-portable way to do the 
> same thing on glibc versions that don't provide it.

I've added a test for the symbol in R-devel.  I did originally expect to 
need one for non-glibc Linuxen (e.g. using Intel and PG compilers) but 
they do find the symbol.  Hopefully this will continue to be the case for 
the major distros.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595