RESOLUTION - Re: debian binary compatability...
Didn't get any takers on this one, so I assume that there arn't too
many elf experts on the list..
Consequently I spent a bit of time reading up on how elf works, and I
think I have gotten to the bottom of it.
In case it helps anyone else, the secret is as follows..
The '.interp' section of the ELF executable specifies the name of the
'dynamic loader' that the kernel transfers control to, which is
responsible for loading the shared libraries into memory, resolving
all remaining relocations, and then transferring control to the application.
This used to always be '/lib/ld-linux.so.1', as indeed it was
in the binary I was trying to run. But with libc6 this seems to
have changed to '/lib/ld-linux.so.2'.
All of the other Linux distros I had tried were keeping the libc5
compatability versions installed by default, but Debian did not -
and the killer was that the error which resulted from a missing loader
was particularly unhelpful.
Unlike the actual loader itself, which names any library it can't
find, if the Kernel can't find the loader, it it pretends that
the original executable didn't exist... :-/
Having now determined that the missing package was altgcc and
installed it, I can now run my original binary and get the much
more helpful (and expected) error message:
Xsetup.text: can't load library 'libtermcap.so.2'
which was easily rectified with an
apt-get install termcap-compat
and now it works!
Regards,
DigbyT
On Mon, Feb 06, 2006 at 11:00:46PM +0000, Digby Tarvin wrote:
> Still trying to work out why binary executables which file(1) identifies
> as:
> ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> dynamically linked (uses shared libs), stripped
>
> Which are part of a non-source commercial Linux application dated from
> around 1998, and ran fine on my SuSE system, won't execute on a
> Debian system, and doesn't even seem to return a sensible error
> message:
>
> strace /tmp/setup
> strace: exec: No such file or directory
> execve("/tmp/setup", ["/tmp/setup"], [/* 17 vars */]) = 0
>
> I get the same result on Debian 2.4 and 2.6 stable kernels.
>
> The old SuSE system was 2.4.10, and I originally thought it might have
> been some backward compatability in my old SuSE kernel that has been
> deprecated in more recent kernels, but I have just tried it on a
> Gentoo system with kernel 2.6.12, and appart from complaining about a
> missing shared library it runs on that as well, so it does appear to
> be a Debian issue.
>
> I have checked my kernel config for any likely looking
> executable format options, don't see any optional ELF formats.
>
> Just to prove it is not a shell oddity, access permissions or
> mistyping a name, here is a trivial test program:
>
> #include <unistd.h>
> char prog[] = "/tmp/setup";
> main()
> {
> int val;
>
> if(access(prog, X_OK) != 0)
> {
> printf("file does not exist\n");
> exit(1);
> }
> val = execl(prog, prog, 0);
> printf("exec returned %d\n", val);
> perror(prog);
> }
>
> which produces the following output:
>
> exec returned -1
> /tmp/setup: No such file or directory
>
> Does anyone have any idea what is going on??
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
Reply to: