From quanah at stanford.edu  Fri Jul 28 19:35:18 2006
From: quanah at stanford.edu (quanah at stanford.edu)
Date: Fri, 28 Jul 2006 19:35:18 +0200 (CEST)
Subject: [Rd] R uses private function in libc (PR#9107)
Message-ID: <20060728173518.BB42D3F03F@slim.kubism.ku.dk>



--On Friday, July 28, 2006 9:23 AM +0100 Prof Brian Ripley 
<ripley at stats.ox.ac.uk> wrote:

> On Fri, 28 Jul 2006, quanah at stanford.edu wrote:
>
>> Full_Name: Quanah Gibson-Mount
>> Version: 2.3.0, 2.3.1
>> OS: Linux
>
> That's not adequate information: see below.
>
>> Submission from: (NULL) (171.66.155.86)
>>
>>
>> libc used to export the symbol:
>>
>> __libc_stack_end;
>>
>> however, newer versions of libc no longer export it.  R has some serious
>
> Please tell us what these `newer versions of libc' are.
>> g<libc does on e.g. 2.3.6 and 2.4, which is AFAICS current.
>
>> problems around this, because the code has:
>>
>> # ifdef linux
>> extern void * __libc_stack_end;
>> # endif
>>
>>
>> and
>>
>> # if defined(linux)
>>     R_CStackStart = (uintptr_t) __libc_stack_end;
>> # elif defined(HAVE_KERN_USRSTACK)
>>
>>
>> in r-2.3.1/src/unix/system.c
>>
>> This code needs to be fixed.  It is causing all sorts of problems when
>> trying to run R across multiple systems with different libc versions.
>
> What are the 'all sorts of problems'?  It seems they are affecting no one
> else, and R is very widely used on Linux systems.  So there is nothing
> here we can reproduce.

Well, here is a little background:

At Stanford, we build software and then make it available to campus via a 
distributed file system (AFS in our case).  In building "R" for our new 
64-bit Linux tree, we encountered this issue after building R on our 64-bit 
Debian Sarge system, which has libc version 2.3.2, and does export 
__libc_stack_end, although it is marked private, as it should be:

readelf -s /lib/libc.so.6 | grep __libc_stack_end
  1144: 0000000000000000     8 OBJECT  GLOBAL DEFAULT  UND 
__libc_stack_end at GLIBC_PRIVATE (9)

After I released the build to campus, we immediately got reports that it 
didn't work on other systems, and finally tracked that down to the newer 
versions of libc on those systems:

bramble01:~> readelf -s /lib/libc.so.6 | grep __libc_stack_end
bramble01:~> ldd --version
ldd (GNU libc) 2.3.6

yen4:~> readelf -s /lib/libc.so.6 | grep __libc_stack_end
  2148: 00000000     4 OBJECT  GLOBAL DEFAULT  UND 
__libc_stack_end at GLIBC_2.1 (22)
  6010: 00000000     4 OBJECT  GLOBAL DEFAULT  UND __libc_stack_end@@GLIBC_2
yen4:~> ldd --version
ldd (GNU libc) 2.3.4


When running "R" on either the bramble or yen systems, the error one gets 
is:

yen4:~> R
/usr/pubsw/lib/R/2.3.1/R/bin/exec/R: relocation error:
/usr/pubsw/lib/R/2.3.1/R/bin/exec/R: symbol __libc_stack_end, version
GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time
reference


bramble01:~> R
/usr/pubsw/lib/R/2.3.1/R/bin/exec/R: relocation error: 
/usr/pubsw/lib/R/2.3.1/R/bin/exec/R: symbol __libc_stack_end, version 
GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time 
reference


For now, I've managed to get around this by patching R thusly:

cat libc
--- r-2.3.1/src/unix/system.c.orig      2006-07-27 17:42:10.000000000 -0700
+++ r-2.3.1/src/unix/system.c   2006-07-27 17:46:42.000000000 -0700
@@ -117,9 +117,9 @@
 #  include <sys/time.h>
 # endif
 # include <sys/resource.h>
-# ifdef linux
+/* # ifdef linux
 extern void * __libc_stack_end;
-# endif
+# endif */
 # ifdef HAVE_KERN_USRSTACK
 #  include <unistd.h>
 #  include <sys/types.h>
@@ -157,9 +157,10 @@
        lim2 = (unsigned long) rlim.rlim_max; /* Usually unlimited */
         R_CStackLimit = lim1 < lim2 ? lim1 : lim2;
     }
-#if defined(linux)
+/* #if defined(linux)
     R_CStackStart = (uintptr_t) __libc_stack_end;
-#elif defined(HAVE_KERN_USRSTACK)
+#elif defined(HAVE_KERN_USRSTACK) */
+#if defined(HAVE_KERN_USRSTACK)
     {
        /* Borrowed from mzscheme/gc/os_dep.c */
        int nm[2] = {CTL_KERN, KERN_USRSTACK};


In any case, as you can see, __libc_stack_end goes away completely by libc 
2.3.6, 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 at lists.debian.org/msg28253.html>

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html



[Rd] R uses private function in libc (PR#9107)
quanah at stanford.edu