Re: ENOEXEC from exec*() functions...?

[Martin Dorey]

Sorry to reanimate this but I think I've run into a regression in 4.2.92 over 4.2.1 that's probably related to this old email thread.  Bug or email, bug or email... email:

martind@swiftboat:~/playpen/make-2019-10-08$ cat > Makefile

all: ; ./dodgy

martind@swiftboat:~/playpen/make-2019-10-08$ cat > dodgy

true

martind@swiftboat:~/playpen/make-2019-10-08$ chmod +x dodgy

martind@swiftboat:~/playpen/make-2019-10-08$ make

./dodgy

make: *** [Makefile:1: all] Error 127

martind@swiftboat:~/playpen/make-2019-10-08$ /usr/bin/make

./dodgy

martind@swiftboat:~/playpen/make-2019-10-08$ strace -f make 2>&1 | grep execve

execve("/usr/local/bin/make", ["make"], [/* 209 vars */]) = 0

[pid 21223] execve("./dodgy", ["./dodgy"], [/* 212 vars */]) = -1 ENOEXEC (Exec format error)

martind@swiftboat:~/playpen/make-2019-10-08$ strace -f /usr/bin/make 2>&1 | grep execve

execve("/usr/bin/make", ["/usr/bin/make"], [/* 209 vars */]) = 0

[pid 21247] execve("./dodgy", ["./dodgy"], [/* 212 vars */]) = -1 ENOEXEC (Exec format error)

[pid 21247] execve("/bin/sh", ["/bin/sh", "./dodgy"], [/* 212 vars */]) = 0

martind@swiftboat:~/playpen/make-2019-10-08$

"make" is 4.2.92 (today's git), where /usr/bin/make is actually 4.0, but 4.2.1 behaves the same.

---

From: Bug-make <bug-make-bounces+martin.dorey=address@hidden> on behalf of Paul Smith <address@hidden>
Sent: Monday, July 30, 2018 07:56
To: Eli Zaretskii <address@hidden>
Cc: address@hidden <address@hidden>
Subject: Re: ENOEXEC from exec*() functions...?

 

On Mon, 2018-07-30 at 17:29 +0300, Eli Zaretskii wrote:
> > Which doesn't sound like something that would be helped by re-
> > running
> > as a shell script.  Maybe this is a feature of GNU/Linux and other
> > systems use ENOEXEC when there's no #! line?
>
> But in GNU Make, SHELL can be set to anything, including a command
> that runs some executables which the Unix kernel and the Unix shell
> don't recognize.  Maybe that code tries to cater to this situation?
> AFAIU, such a situation will not be resolved by execvp's fallback to
> the shell, because I presume execvp will call the standard shell,
> right?

Well, this code won't help with that.

It will run "/bin/sh foo bar" and the execvp() call will succeed and
the process will be replaced by the shell.  If "foo" is not a shell
script then the shell will still try to run it and fail with some sort
of syntax error or something.  That will be a very different error than
execvp() returning ENOEXEC.

The only way you'd get ENOEXEC here is if, I suppose, execvp() couldn't
find a shell at all.  Even then you probably just get ENOENT (I didn't
hide /bin/sh on my system to test this :)) which is what you'd get for
any other non-existent program.

As far as I can tell the only way execvp() can return ENOEXEC is if you
try to run a 64bit binary on a 32bit system, or a Windows binary on a
GNU/Linux system, or something like that: something where the kernel
can't even load the program.

_______________________________________________
Bug-make mailing list
address@hidden
https://na01.safelinks.protection.outlook.com/?url="">