problem with executables
dbn.lists at gmail.com
Sat Nov 26 10:58:57 PST 2005
On 11/26/05, jstipins at umich.edu <jstipins at umich.edu> wrote:
> And this seems to happen for any binary which was compiled on a 2.4 kernel,
> not just this one.
> What exactly is happening here?
I could be wrong, but this seems to be the --enable-kernel in glibc
business. You won't be able to execute those binaries since as Ken
said, there trying to use the 2.4 glibc kernel interfaces, and you've
specified to only use 2.6+ interfaces when you compiled glibc with
You could rebuild glibc without the --enable-kernel flag (I forget
what the other relevant targets are), however, I can't say with any
certainty that it would work. Like Ken said, if it's 2.4, it may be
using Linuxthreads, and the glibc LFS builds now defaults to NPTL.
So, I don't know if a pre-compiled binary would work unless it was
compiled with NPTL, which is unlikely since it's looking for 2.4.1 and
I don't think that NPTL is compatible with that version of Linux.
Take a look at this enlightening read from Ulrich Drepper about glibc
kernel interfaces and LD_ASSUME_KERNEL.
This is where I bow out because I've never really tried any of this
stuff. It's mostly speculation from the bits of toolchain reading
I've done. I could be wrong, but I think that if you want to use old
binaries, you'll might need to have your glibc built with linuxthreads
rather than nptl. That would suck because nptl is a major upgrade
from linuxthreads as shown in another Drepper read:
Again, I'm speculating, but I think you may need to have multiple
glibc's to support both linuxthreads and nptl. And I don't know that
anyone around here has pulled that off. I know that on our RHEL3
multilib system at work we have /lib/libc.6.so, /lib/i686/libc.so.6,
/lib/tls/libc.so.6, /lib64/libc.so.6, /lib64/x86-64/libc.so.6, and
/lib64/tls/libc.so.6. Doesn't look fun to operate.
Anyone care to correct what I've said, please chime in.
More information about the cross-lfs