--On Friday, July 28, 2006 9:23 AM +0100 Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> On Fri, 28 Jul 2006, [EMAIL PROTECTED] 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
[EMAIL PROTECTED] (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
[EMAIL PROTECTED] (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@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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
