<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/14/2013 10:21 AM, Ron Frazier
(ALE) wrote:<br>
</div>
<blockquote
cite="mid:b07fefec-859a-4892-9fad-73963d9f6c26@email.android.com"
type="cite">
<pre wrap="">They REALLY should put an appropriate descriptive error message.</pre>
</blockquote>
<br>
It's like anything else—once you know what it means, it makes
sense. The world is full of cryptic information that we humans have
to decode. The POSIX interface, however, is well-defined and there
are a finite number of things that can cause an error.<br>
<br>
<blockquote
cite="mid:b07fefec-859a-4892-9fad-73963d9f6c26@email.android.com"
type="cite">
<pre wrap="">Like, "The superapp application failed to run because its executable bit is off." or "The emulator application failed while trying to load xxx.yyy library."</pre>
</blockquote>
<br>
POSIX errors are sufficiently descriptive. Consider what happens
when you're sitting at a shell prompt and run "ls":<br>
<ol>
<li>The shell will look for a file named "ls" to execute. This
involves searching the PATH for a file that is named "ls" and is
executable.</li>
<li>If a file named "ls" is not found in the PATH, the shell says
"command not found".</li>
<li>If a file named "ls" is in the PATH, but it is not executable,
the shell says "command not found".</li>
<li>If a file named "ls" is found and it is executable, the shell
asks the kernel to run it.</li>
</ol>
<p>Now, what happens if "ls" is a binary, is executable, and is of
the wrong architecture?<br>
</p>
<p>For that information, refer to the execve(3) man page (say "<b>man
3 execve</b>" to the shell).<br>
</p>
<p>I'll continue, though, about how program execution works here.<br>
</p>
<p>Let's say that you have ls, and it is for ARM. When you try to
run it:<br>
</p>
<p>[mbt@aloe ~]$ file ls<br>
ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=be286f4b922f48718ca564b4eb9eb406407e4f3d, stripped<br>
[mbt@aloe ~]$ ./ls<br>
/lib/ld-linux.so.3: No such file or directory<br>
</p>
<p>Why? I don't have the file! The kernel went ahead and attempted
to load the ELF interpreter mentioned in the file, because there
is a chance that the ELF interpreter might know how to read the
file and give the kernel guidance on how to run it. (Yes, ELF's
format does actually support multiple-purpose usage; it doesn't
just have to be a conatiner for native code!) Additionally, it is
important to note that on my system (Fedora 20 prerelease), an ARM
ELF image will be executed with /usr/bin/qemu-arm automatically.<br>
</p>
<p>No such file or directory makes sense here, because <i>it is the
error which caused the execution to fail.</i> What happens if I
have that file, then?<br>
</p>
<p>To find out, I've symlinked my dynamic loader to the requested
name, ld-linux.so.3. Now:<br>
</p>
<p>[mbt@aloe ~]$ ./ls<br>
/lib/ld-linux.so.3: Invalid ELF image for this architecture<br>
</p>
<p>Hrm. Why?<br>
</p>
<p>Because the ARM code emulator doesn't know how to talk to ELF
x86-64 libraries!<br>
</p>
<p>What happens if I remove its ability to load the ARM emulator,
though? To do that, I will remove the
/proc/sys/fs/binfmt_misc/qemu-arm file from my system (it will
come back at next boot):<br>
</p>
<p>echo -1 > /proc/sys/fs/binfmt_misc/qemu-arm<br>
</p>
<p>This removes the entry from the system. Now what happens?<br>
</p>
<p>[mbt@aloe ~]$ ./ls<br>
-bash: ./ls: cannot execute binary file<br>
</p>
<p>This is what happens when you have something that truly cannot be
executed. To find out the why you can use strace:<br>
</p>
<p>[mbt@aloe ~]$ strace ./ls<br>
execve("./ls", ["./ls"], [/* 73 vars */]) = -1 ENOEXEC (Exec
format error)<br>
write(2, "strace: exec: Exec format error\n", 32strace: exec: Exec
format error<br>
) = 32<br>
exit_group(1) = ?<br>
+++ exited with 1 +++<br>
[mbt@aloe ~]$ <br>
<br>
</p>
<blockquote
cite="mid:b07fefec-859a-4892-9fad-73963d9f6c26@email.android.com"
type="cite">
<pre wrap="">(Yes, to any newbies reading, you may get a file not found error on Ubuntu 12.04 and Mint 13 and possibly others if the executable bit in the file properties is off.</pre>
</blockquote>
<br>
Of course you will—the executable bit isn't set. It's like having
CMD.EX_ instead of CMD.EXE on a Windows box; it won't be found it if
doesn't comply with the expectations that the system has of it.<br>
<br>
<blockquote
cite="mid:b07fefec-859a-4892-9fad-73963d9f6c26@email.android.com"
type="cite">
<pre wrap="">Well horsefeathers. I just tested this by taking away the executable permission from the LS command. It then gives a permissions error. However, I'm pretty sure I've seen this manifest as a file not found error too.)</pre>
</blockquote>
<br>
No, you should have an error like this:<br>
<br>
[root@aloe ~]# ls<br>
-bash: /bin/ls: Permission denied<br>
<br>
Which will happen if ls has no permission for execute.<br>
<br>
If a directory in your PATH has no execute permissions and you're
using an older system, you'll get a more generic permission denied
message that doesn't actually mention the file itself. I can't
replicate that on my system because it doesn't follow that behavior
anymore; bash (or exec(), not sure which) is actually skipping any
directories in $PATH with bad permissions now. Yay!<br>
<br>
<br>
<blockquote
cite="mid:b07fefec-859a-4892-9fad-73963d9f6c26@email.android.com"
type="cite">
<pre wrap="">Or better yet, (what I said above) + "error code 2342". Which you could then google. And / or, print a trace of the last 10 commands.</pre>
</blockquote>
<br>
POSIX errors already have codes, and they're much easier to
remember. They are symbols; e.g., E2BIG, EACCES, EINVAL, ELOOP.<br>
<br>
However, we don't expose them to the user always, because we don't
need to. If you are asking your shell to execute something and it
cannot do so, it is up to you to investigate why. This is standard
practice.<br>
<br>
<blockquote
cite="mid:b07fefec-859a-4892-9fad-73963d9f6c26@email.android.com"
type="cite">
<pre wrap="">What really confused me is that I'd already run the emulator, albeit insanely slowly, on my laptop. This missing file phenomena never happened. But ... that vm is 32 bit, not 64 bit.</pre>
</blockquote>
<br>
That'd be why.<br>
<br>
<blockquote
cite="mid:b07fefec-859a-4892-9fad-73963d9f6c26@email.android.com"
type="cite">
<pre wrap="">These events of pounding on something that is already (as far as I could tell) properly configured put serious dents in my already dented sanity, at least temporarily.</pre>
</blockquote>
<br>
You just have gaps in your knowledge, that's all. You need to spend
some time studying the system that you're working with <b><i>before</i></b>
trying to do very advanced things with it.<br>
<br>
You should not be developing for any system if you cannot
troubleshoot a file execution issue relatively quickly. You do need
to know the system you're developing <i><b>on</b></i>, or you're
going to have a very hard time proceeding.<br>
<br>
— Mike<br>
<br>
<div class="moz-signature">-- <br>
<table border="0">
<tbody>
<tr>
<td> <img src="cid:part1.05030602.05080306@naunetcorp.com"
alt="Naunet Corporation Logo"> </td>
<td> Michael B. Trausch<br>
<br>
President, <strong>Naunet Corporation</strong><br>
☎ (678) 287-0693 x130 or (855) NAUNET-1 x130<br>
FAX: (678) 783-7843<br>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>