From: Luca Barbieri <luca.barbieri@gmail.com>
To: Ulrich Drepper <drepper@gmail.com>
Cc: Olaf van der Spek <olafvdspek@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: execve() returns ENOENT when ld-linux.so isn't found
Date: Sat, 27 Mar 2010 15:51:52 +0100 [thread overview]
Message-ID: <ff13bc9a1003270751j5c138690p93afb7659d8d745d@mail.gmail.com> (raw)
In-Reply-To: <a36005b51003261415u1cc89f84r843abaa81f1d7396@mail.gmail.com>
> That argumentation is bogus. You wrote yourself, this situation isn't
> (and cannot) be described in POSIX. For such cases the any error
> value is consistent with POSIX.
Sure, but that means POSIX also does not forbid changing it.
> Again: any value is as good as any other. The existing value works
> and changing it breaks existing code.
Yes, this is an argument in favor of leaving it as is.
> Changing the error code alone achieves nothing.
If you were to change it to a new error value, such that
strerror(errno) == "unable to open ELF interpreter" (or similar), that
would just work.
The problem is that would only work after upgrading glibc, and would
probably break the error reporting code in RH shells if only the
kernel is upgraded.
A possibly better option is to add the ability to the kernel to report
extended error strings (was proposed some time ago), and use that.
It's a small issue, but I recently stumbled on it when running an x86
binary on an x86-64 machine lacking the compat libraries, and it's
quite suprising at first to have the shell claim the file does not
exist when it clearly does (and would be even more so for people who
don't know anything about executables or ELF).
The idea of parsing the ELF file in the shell seems quite ugly, since
you need to add a non-trivial piece of code at least to all shells and
all graphical file managers.
glibc itself could conceivably provide functions to do that
(strerror_for_exec* or exec*_with_extended_error ?).
next prev parent reply other threads:[~2010-03-27 14:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b2cc26e41003241537h228028c4n1374f4b042175885@mail.gmail.com>
2010-03-24 22:45 ` drepper
2010-03-25 19:29 ` Olaf van der Spek
2010-03-25 21:00 ` Luca Barbieri
2010-03-26 11:56 ` Ulrich Drepper
2010-03-26 18:40 ` Olaf van der Spek
2010-03-26 21:06 ` Luca Barbieri
2010-03-26 21:15 ` Ulrich Drepper
2010-03-27 11:50 ` Olaf van der Spek
2010-03-27 12:05 ` Ulrich Drepper
2010-03-29 14:40 ` Olaf van der Spek
2010-03-29 14:57 ` Ulrich Drepper
2010-03-29 16:00 ` Andreas Schwab
2010-03-31 19:36 ` Olaf van der Spek
2010-03-27 14:51 ` Luca Barbieri [this message]
2010-03-18 14:42 Olaf van der Spek
2010-03-24 13:35 ` Olaf van der Spek
2010-03-24 13:49 ` drepper
2010-03-24 22:10 ` Olaf van der Spek
2010-03-24 22:35 ` drepper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ff13bc9a1003270751j5c138690p93afb7659d8d745d@mail.gmail.com \
--to=luca.barbieri@gmail.com \
--cc=drepper@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olafvdspek@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®