Summary: PATH not honored when --disable-posix-spawn is not
Submitted by: None
Submitted on: Fri 30 Aug 2019 12:20:12 PM UTC
Severity: 3 - Normal
Item Group: Bug
Assigned to: None
Discussion Lock: Any
Component Version: SCM
Operating System: POSIX-Based
Fixed Release: None
Triage Status: None
When i build (under linux) make-4.2.90 without --disable-posix-spawn (and not
--disable-pthread-spawn, a typo in NEWS), the PATH variable (set in the
Makefile) is not honored. This is new compared to make-4.2.1.
> Update of bug #56834 (project make):
> Status: None => Fixed
> Assigned to: None => psmith
> Open/Closed: Open => Closed
> Fixed Release: None => SCM
> Triage Status: None => Medium Effort
> Follow-up Comment #1:
> I've pushed a fix for this issue. It will be available in the next release of
> GNU make. Thanks for testing!
> Reply to this item at:
> Message sent via Savannah
> https://savannah.gnu.org/ >
> Bug-make mailing list
> [hidden email] > https://lists.gnu.org/mailman/listinfo/bug-make
I cannot compile from the source since the following commit:
Author: Paul Smith <[hidden email]>
Date: Fri Sep 6 22:24:46 2019 -0400
[SV 56834] Support local PATH search with posix_spawnp
I see the following error message on Ubuntu LTS 18.04.
Re: [bug #56834] PATH not honored when --disable-posix-spawn is not used
On Wed, 2019-09-11 at 18:14 +0900, Masahiro Yamada wrote:
> I cannot compile from the source since the following commit:
Your local install of gnulib is too old. Please pull the very latest
gnulib master HEAD from Git.
I proposed a patch to gnulib's findprog module to provide some
functionality I wanted and Bruno added (a slightly different
Unfortunately, not even this will work correctly because right after I
pushed my changes that use this, Bruno pushed another commit that
changed the way the definition of the new function was called which
broke my invocation of it.
If you want to compile from source right now you need to pull the
latest gnulib then do something like:
git reset --hard 3578d0622666eba42
to get the version that GNU make expects.
I personally think the new change is unnecessary, but if it hasn't been
put back in a day or two I'll change GNU make's call to match.