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=hds....@gnu.org> on behalf of
Paul Smith <psm...@gnu.org>
Sent: Monday, July 30, 2018 07:56
To: Eli Zaretskii <e...@gnu.org>
Cc: bug-make@gnu.org <bug-make@gnu.org>
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
Bug-make@gnu.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnu.org%2Fmailman%2Flistinfo%2Fbug-make&data=01%7C01%7CMartin.Dorey%40hitachivantara.com%7C07a28247064f4b95485508d5f62cae39%7C18791e1761594f52a8d4de814ca8284a%7C0&sdata=%2Bb5jGO7LiqcJFE34LjHbW7LPiSn1nTjdyV8gyf6BAfw%3D&reserved=0
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
