This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
glibc supporting legacy kernels < 2.4.20?
- From: ttk <ttk448 at gmail dot com>
- To: libc-help at sourceware dot org
- Date: Mon, 20 Feb 2012 17:31:36 +0000
- Subject: glibc supporting legacy kernels < 2.4.20?
- Authentication-results: mr.google.com; spf=pass (google.com: domain of ttk448@gmail.com designates 10.60.5.193 as permitted sender) smtp.mail=ttk448@gmail.com; dkim=pass header.i=ttk448@gmail.com
I'd like to compile a glibc 32 bit version which can be used to produce static
executables which run on a wide range of linux kernels (including 2.2.x and
2.0.x if at all possible). However, from my tests I believe 2.4.20 might be the
minimum kernel version still being supported (due to tls), right?
Anyway, I've used glibc-2.14.tar.bz2:
../configure --prefix=/usr/local/glibc_32 \
--enable-kernel=2.0.0 \
--with-cpu=i486 --host=i486-linux-gnu \
CC="gcc -m32 -march=i486" CXX="g++ -m32 -march=i486"
[...]
WARNING: minimum kernel version reset to 2.0.10
[...]
That looked all good and compiled just fine (except that using --with-cpu=i386
would not compile, but i486 is also fine). Now, compiling a simple
test programme
and statically linking against this glibc version and executing the binary on a
2.2.x kernel produces:
$ ./prog
set_thread_area failed when setting up thread-local storage
Segmentation fault
Ok, looking at the source code it seems like it is caused by
./glibc-2.14/nptl/sysdeps/i386/tls.h
when it calls assembly int 0x80, with the parameter __NR_set_thread_area, which
I believe is only available since kernel 2.4.20:
$ grep __NR_set_thread_area /usr/src/linux-2.4.20/include/asm-i386/unistd.h
#define __NR_set_thread_area 243
So either I've made some stupid mistake or maybe the glibc configure
script should
reset minimum supported kernel version to 2.4.20 (so that the error message now
would be the usual "FATAL: kernel too old")?
Also, the configure script has options --without-__thread or
--without-tls, but then glibc
won't compile. Wouldn't it be less confusing to just simply remove
these options?
Any other options to make static executables run on older kernel versions?