Document the brokenness of binaries linked against /lib/ld-linux.so.1

[jdreed]

See ATN-41 for details. Running old binaries (ez, for example) produces the incorrect error message "command not found", when what it really can't find is the interpreter. We should document this, and possible provide something like "athrun consult checkbinary" or maybe just "strings foo | grep -i ld-linux.so.1"

Also see LP335666 for the upstream bug.

[jdreed]

As per the comment on LP335666, we should try and get this upstream into the kernel.

[jdreed]

Documentation done and in Hermes.

I'm going to change the metadata for this to more accurately reflect what we need to do.

We should decide if we still care enough to try and get LP335666 into the kernel. I'm willing to bet we're the only site that still has a bunch of libc5 binaries lying around for people to trip over. I'd rather spend the time and effort in desupporting ancient lockers.

[broder]

Not true, actually. I ran into this bug (or something very like it) when I was working on a cross-compiler toolchain for my phone. Long story, but the short version is that I found the pre-built compiler that Palm was supposedly using, and I was getting ENOENTs when I tried to run them on my Jaunty VM. So I think this is still worth pushing, but through kernel.org, not through LP.

[geofft]

jdreed said he'll take care of documenting this for fall release, although we should still get this fixed in the kernel or something as a good deed to the world.

[jdreed]

Documented ( http://kb.mit.edu/confluence/x/zTlB)