[bug #58639] Shortest stem not matched

Follow-up Comment #2, bug #58639 (project make): Paul, do you think we can describe this scenario this explicitly in the doc? E.g. diff --git a/doc/make.texi b/doc/make.texi index 733c0b9..9c625d7 100644 --- a/doc/make.texi +++ b/doc/make.texi @@ -10342,9 +10342,9 @@ A pattern rule can be used

Re: simple assignment of target-specific variables

On Tue, Jun 9, 2020 at 12:01 PM David Boyce wrote: > When I say "needed" here I mean specifically that the recipe runs. Clearly a > target-specific variable is 'needed' iff the target is built. It's not a > question of how many places the variable is expanded, it's a boolean thing: > the

Re: simple assignment of target-specific variables

On Tue, Jun 9, 2020 at 9:46 AM Edward Welbourne wrote: > I presume the workaround is > > TGTDATE := $(shell date) > $(TARGETS): DATE := $(TGTDATE) > > at the slightly annoying price of calling the command once even if > making some target *not* in the TARGETS list. It is possible to avoid this

Re: simple assignment of target-specific variables

On Tue, Jun 9, 2020 at 9:10 AM David Boyce wrote: > TARGETS := aa bb cc dd > $(TARGETS): at := $(shell set -x; date) Despite the same name "at" those are different variables. Given that there are 4 simple variables defined, 4 calls to date take place. $ cat makefile .PHONY: all all: aa bb aa:

[bug #58497] inconsistent newline removal in $(file <)

Follow-up Comment #2, bug #58497 (project make): However, i'd like to be able to reproduce realloc returning a smaller address. Ken, do you have a makefile which reproduces this? ___ Reply to this item at:

[bug #58497] inconsistent newline removal in $(file <)

Follow-up Comment #1, bug #58497 (project make): Attached another fix along with new tests. ___ Reply to this item at: ___ Message sent via Savannah

[bug #58497] inconsistent newline removal in $(file <)

Additional Item Attachment, bug #58497 (project make): File name: sv_58497_fix_function_file.diff Size:0 KB File name: sv_58497_fix_function_file_tests.diff Size:2 KB

[bug #58435] make 4.3 is not c89 compliant

Follow-up Comment #2, bug #58435 (project make): This code was introduced when a local implementation of strerror was replaced with gnulib's one. commit 4d00ceba264a9fd04241dcd2685526ce64c1346b Author: Paul Smith Date: Sat Jul 13 08:34:45 2019 -0400 Switch to the gnulib version of

[bug #58365] make 4.3 segfault on s390x alpine linux

Follow-up Comment #1, bug #58365 (project make): Can you please attach a makefile which reproduces the crash? ___ Reply to this item at: ___ Сообщение

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #4, bug #56301 (project make): This test is the same as the one submitted earlier, but unlinks the included makefiles. diff --git a/tests/scripts/features/include b/tests/scripts/features/include index 0c63c06..4401622 100644 --- a/tests/scripts/features/include +++

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #3, bug #56301 (project make): These patches are against the current master (0c326a66c9eb3a3b5e4ab7892578b016b0590b1f). ___ Reply to this item at:

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

Additional Item Attachment, bug #55242 (project make): File name: sv_55242_let_included_files_be_byproduct_of_unrelated_rules.diff Size:2 KB File name:

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

Follow-up Comment #2, bug #55242 (project make): Here is a test. diff --git a/tests/scripts/features/include b/tests/scripts/features/include index 0c63c06..f39e5ec 100644 --- a/tests/scripts/features/include +++ b/tests/scripts/features/include @@ -260,4 +260,16 @@ inc1:; @%s $@ && echo FOO :=

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

Follow-up Comment #1, bug #55242 (project make): Here is a patch against the current master (0c326a66c9eb3a3b5e4ab7892578b016b0590b1f). This patch causes make to re-execute itself to read the included makefile. diff --git a/src/remake.c b/src/remake.c index fb237c5..4dc91d8 100644 ---

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #2, bug #56301 (project make): Here is a test. diff --git a/tests/scripts/features/include b/tests/scripts/features/include index 0c63c06..2281ee4 100644 --- a/tests/scripts/features/include +++ b/tests/scripts/features/include @@ -260,4 +260,13 @@ inc1:; @%s $@ && echo FOO :=

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #1, bug #56301 (project make): Here is a fix. diff --git a/src/main.c b/src/main.c index bcba2d1..5c1a7da 100644 --- a/src/main.c +++ b/src/main.c @@ -2305,6 +2305,8 @@ main (int argc, char **argv, char **envp) any_remade |= (mtime != NONEXISTENT_MTIME

Re: make-4.3: wildcard test #9 fails

> On Sun, 2020-04-05 at 16:19 +0200, Bruno Haible wrote: > > > > Building GNU make 4.3 on Ubuntu 16.04, produces one failing test: On filesystems which don't populate dirent::d_type (or on old glibc) test 7 also fails. I just asked gnulib mailing list to look at a patch.

[bug #58056] Forced prerequisite order is not honored with pattern rules

Follow-up Comment #1, bug #58056 (project make): This behavior is intended. 1. To figure out if a target has to be rebuilt make traverses the list of prerequisites and finds out if any of the prerequisites, but not intermediate prerequisites, need to be rebuilt. During this traverse make

[bug #58013] .SILENT no longer suppresses "Entering directory"

Follow-up Comment #7, bug #58013 (project make): Posix is explicit that -s and .SILENT are both about command lines. If we wanted to be strictly posix conformant 'Entering directory' should be printed even when -s is specified. if .SILENT is stretched to suppress other messages such as 'Entering

[bug #58013] .SILENT no longer suppresses "Entering directory"

Follow-up Comment #4, bug #58013 (project make): "Entering directory' message when the user is not expecting one is a benign backward incompatibility. i'd be more concern about the opposite. Also, reinstating the prior behavior is incompatible with 4.3.

[bug #58013] .SILENT appears to be ignored in GNU Make 4.3

Follow-up Comment #1, bug #58013 (project make): This is intentional. See https://savannah.gnu.org/bugs/?54740. ___ Reply to this item at: ___ Message

[bug #57676] openjdk11 fails to build with make 4.3

Follow-up Comment #10, bug #57676 (project make): Here is a test for this. +# Test 20. +# When successfully read an included makefile, update its mtime, if needed. +# https://savannah.gnu.org/bugs/?57676. + +unlink('hello.mk'); +run_make_test(q! +-include hello.mk +$(shell echo hello=world

[bug #57676] openjdk11 fails to build with make 4.3

Follow-up Comment #9, bug #57676 (project make): make should not claim "cannot make the included makefile" having successfully read the makefile. Here is a patch which fixes the issue. regards, Dmitry diff --git a/src/makeint.h b/src/makeint.h index c428a36..327849b 100644 --- a/src/makeint.h

Re: Defining and exporting and a variable undefined in a foreach loop cause a Segmentation fault with Make 4.2.1 on Debian bullseye/sid x64

On Thu, Mar 5, 2020 at 10:45 AM Xavier Sanchez wrote: > > Hi, I've got a segfault in __strlen_avx2 () at > ../sysdeps/x86_64/multiarch/strlen-avx2.S:65 > > While defining a variable that has been undefined in a foreach loop using Make > 4.2.1 on my Bullseye/sid workstation. Does not reproduce

[bug #57962] apparent regression involving PATH resolution

Follow-up Comment #5, bug #57962 (project make): i also submitted this patch to bug-gnulib mailing list. ___ Reply to this item at: ___ Message sent

[bug #57962] apparent regression involving PATH resolution

Follow-up Comment #4, bug #57962 (project make): The bug is in gnulib in function find_in_given_path. This is a patch which fixes the bug. The fix is likely needed for the windows specific piece of code in find_in_given_path as well. regards, Dmitry diff --git a/lib/findprog-in.c

[bug #57962] apparent regression involving PATH resolution

Follow-up Comment #3, bug #57962 (project make): This is a test which reproduces the bug. The bug only manifests when USE_POSIX_SPAWN is defined. regards, Dmitry diff --git a/tests/scripts/features/exec b/tests/scripts/features/exec

Re: Phony targets not being made

On Sun, Feb 16, 2020 at 5:35 PM Peter Dons Tychsen wrote: > There are no implicit rules used in the example AFAIK. '%-sim: %' is the intended implicit rule that make does not look for because rr1-sim is phony. > They are all phony, but not implicit unless i am missing something. Targets could

Re: Phony targets not being made

Good morning. Your makefile is incorrect. Make does not search implicit rules for phony targets. regards, Dmitry On Thu, Feb 13, 2020 at 2:31 PM wrote: > > Hi > > I have the following makefile > -- > PHON1 := rr1 rr2 > PHON2 := rr1-sim > > .PHONY: all $(PHON1) > # remove below line to get

[bug #57778] Stop looking for an included file once found, even if cannot be opened.

URL: Summary: Stop looking for an included file once found, even if cannot be opened. Project: make Submitted by: dgoncharov Submitted on: Sun 09 Feb 2020 05:07:07 PM UTC Severity: 3

Re: make-4.2.93 patch fix compilation in -ansi/-std=c99 mode

On Sat, Jan 4, 2020 at 3:23 PM Paul Smith wrote: > Thanks, I did something similar to this but not quite the same. Have you pushed? > It's a bit strange because I don't see that same error on my system and in > fact, I don't have that code in my sys/wait.h file; I'm using GNU libc > 2.30. Maybe

Re: patch, new test features/exec.

On Fri, Jan 3, 2020 at 12:10 PM Paul Smith wrote: > On Mon, 2019-10-14 at 22:21 -0400, Dmitry Goncharov via Bug reports and > discussion for GNU make wrote: > > This patch adds a new test features/exec. > > I added this test with a few adjustments. Thank you. i am glad to

make-4.2.93 patch port to c90

Good morning. This patch replaced a c99 piece of code with c90 code. This c99 piece of code does not compile with the default ./configure && make. Also, -std=c99 removes __attribute__. regards, Dmitry diff --git a/src/file.c b/src/file.c index 2f1425e..acc8c0c 100644 --- a/src/file.c +++

make-4.2.93 patch enhance error reporting from the test suite

Good morning. This patch enhances error reporting from the test suite. E.g. Clearing work... cannot unlink work/features/.nfs00c262d501ec: Device or resource busy cannot unlink work/features: Is a directory ./run_make_tests.pl: 697: Couldn't wipe out work: Is a directory regards,

make-4.2.93 patch fix compilation in -ansi/-std=c99 mode

Good morning. job.c fails to compile on glibc when -ansi or -std=c99 is specified. ../src/job.c: In function 'reap_children': ../src/job.c:753: error: incompatible type for argument 1 of 'wait' /usr/include/sys/wait.h:116: note: expected '__WAIT_STATUS' but argument is of type 'int *' This

[bug #57242] Non-recursive command passes invalid jobserver file descriptors

Follow-up Comment #1, bug #57242 (project make): Stefan, the behavior you described is intended. make closes the pipe unless the command has + or (MAKE) or {MAKE}. This is necessary, because a command can mess up job server operation or a command may expect a specific fd to be available.

[bug #57022] Error 127 executing a script with no #!

Follow-up Comment #6, bug #57022 (project make): Submitted a new test features/exec which reproduces this bug. https://lists.gnu.org/archive/html/bug-make/2019-10/msg00046.html ___ Reply to this item at:

patch, new test features/exec.

Good morning. This patch adds a new test features/exec. features/exec tests that make can execute binaries as well as scripts with various shabangs and without a shebang and also with various values of SHELL=. The test demonstrates that the current (4.2.92) implementation fails to execute a shell

Re: [PATCH] Port functions/shell to Solaris 10

On Fri, Oct 11, 2019 at 4:25 PM Paul Eggert wrote: > One possibility is that the version of Perl shipped with Solaris is so old > that it predates this Perl standardization. It is a bit of a mess. Actually this patch fixes the same issue on aix with perl-5.10.1 regards, Dmitry

[bug #57022] Error 127 executing a script with no #!

Follow-up Comment #4, bug #57022 (project make): 1. gmake posix_spawn's dodgy 2. fork inside posix_spawn succeeds and posix_spawn returns 0. 3. gmake skips fallback to /bin/sh because posix_spawn's return code is not enoexec. 4. posix_spawn's child proceeds to exec dodgy and fails 5. posix_spawn

Re: [bug #57014] make-4.2.91 segfaults under Solaris 10 when many files are involved

On Mon, Oct 7, 2019 at 11:33 AM Paul Smith wrote: > Unfortunately it's not easy to build from Git unless you have a full > suite of autotools available. Denis, if you cannot built from git, can you enable core dumps and run dbx and post the backtrace here? This is what is look like for me $ dbx

Re: [bug #57014] make-4.2.91 segfaults under Solaris 10 when many files are involved

On Mon, Oct 7, 2019 at 9:03 AM anonymous wrote: > With the following Makefile, make-4.2.91 segfaults on my Solaris 10: ... > include /dev/null > dummy: subdir/*.c > include /dev/null This reproduces for me. This is the same read past the end of the string inside sum_up_to_nul that is already

Re: gmake-4.2.90 regression (segmentation fault in sum_up_to_nul )

On Tue, Sep 24, 2019 at 1:01 PM Paul Smith wrote: > The reason for the "special" code here is > performance, and unfortunately the solution proposed will reduce > performance by a measurable amount (not huge but measurable). Paul, is this call to strlen that you are concerned with? It is

Re: gmake-4.2.90 regression (segmentation fault in sum_up_to_nul )

:01 PM Paul Smith wrote: > > On Tue, 2019-09-03 at 04:14 +, Dmitry Goncharov via Bug reports and > discussion for GNU make wrote: > > sum_up_to_nul reads 4 bytes starting from the passed string 'p'. > > 'p' can have fewer than 4 bytes. Usually there more allocated space

Re: patch, test suite fails to run valgrind

On Sat, Sep 21, 2019 at 04:54:59PM -0400, Paul Smith wrote: > I pushed a different fix for this issue. Thanks for noticing! Thank you. Do you intentionally avoid $! in the "Cannot execute" error message? regards, Dmitry > ___ Bug-make mailing list

patch, test suite fails to run valgrind

Good morning. The test suite fails to run valgrind with an error message like the following. $ ./run_make_tests -memcheck -make_path ../l64/make features/archives ... ok (12 passed) features/comments ... *** Test died

Re: patch locale settings

On Sun, Sep 15, 2019 at 10:14:07AM -0400, Paul Smith wrote: > I see. I wonder why it works for me. i was thinking your system couldn't do anything other than the default, but your german test demonstrates it can. > > > Let me come up with a fix for 'perl run_make_tests.pl'. if you set use

Re: patch locale settings

On Sun, Sep 15, 2019 at 08:31:39AM -0400, Paul Smith wrote: > That's because before we try to detect these messages we explicitly set > the locale in Perl; see test_driver.pl: > > my $loc = undef; > if ($has_POSIX) { > $loc = POSIX::setlocale(POSIX::LC_MESSAGES); >

Re: patch locale settings

On Sat, Sep 14, 2019 at 6:27 PM Paul Smith wrote: > Your setting of LANG or LC_MESSAGES > cannot make any difference to the test suite because the test suite > does not pass those values to the make that it invokes. Paul, that's the output from the perl program (called base) that is affected by

Re: patch locale settings

On Sat, Sep 14, 2019 at 10:22 AM Paul Smith wrote: > and, I've checked with a makefile invoked by the test suite and this > setting is in effect, even if the shell invoking run_make_tests.pl has > a different setting for LC_ALL. This should be sufficient. > Furthermore, we clear out the

Re: patch out of source builds

On Sat, Sep 14, 2019 at 10:19:56AM +0300, Eli Zaretskii wrote: > > This patch makes the test suite look for config.status in the -make_path > > directory to allow testing out of source builds. > > Thanks, but I don't think relying on config_status is good enough, > because some builds don't have

patch locale settings

Multiple tests fail when locale related env variables (such as LANG or LC_MESSAGES) are set to some regional setting. regards, Dmitry diff --git a/tests/run_make_tests b/tests/run_make_tests index b68b784..7b3719e 100755 --- a/tests/run_make_tests +++ b/tests/run_make_tests @@ -1,2 +1,3 @@

patch realpath on aix

aix implementation of realpath returns a path with a trailing slash given a path with 2 or more trailing slashes. This makes realpath test fail. $ echo 'all: ; @echo $(realpath /tmp/)' | ../i32/make -f- /tmp $ echo 'all: ; @echo $(realpath /tmp//)' | ../i32/make -f- /tmp/ Since both posix and

patch out of source builds

Good morning. This patch makes the test suite look for config.status in the -make_path directory to allow testing out of source builds. regards, Dmitry diff --git a/tests/README b/tests/README index 0cb7eac..5ecf392 100644 --- a/tests/README +++ b/tests/README @@ -82,12 +82,9 @@ ChangeLog in

Re: vpathplus test 2 patch

On Wed, Sep 11, 2019 at 2:51 AM Andreas Schwab wrote: > > > The new hashing mechanism hashes differently on big vs little endian. > > Should this be considered as a bug? I don't think the order or removal of intermediate files was specified. Do you have a specific use case in mind, Andreas?

vpathplus test 2 patch

The new hashing mechanism hashes differently on big vs little endian. This makes vpathplus test 2 fail, because the order of intermediate files inter.b and inter.c is now dependent on endiannes. regards, Dmitry diff --git a/tests/scripts/features/vpathplus b/tests/scripts/features/vpathplus

patch to fix grouped_targets test 1

Good morning. echo -n is not portable. Certain implementations of echo everything, including -n. This makes test 1 of grouped_targets fail. regards, Dmitry diff --git a/tests/scripts/features/grouped_targets b/tests/scripts/features/grouped_targets index ef9366b..4d2c9d2 100644 ---

patch to fix features/archives test 10 on sunos

Good morning. ar add output is system dependent. This makes features/archives test 10 fail on sunos. This patch uses the output of `ar rv` rather than a hardcoded string. linux $ ar rv libxx.a 1234567890123456b a - 1234567890123456b sunos $ ar rv libxx.a 1234567890123456b a - 1234567890123456b

Re: gmake-4.2.90 regression (error message missing)

to support cross compilation. regards, Dmitry On Mon, Sep 2, 2019 at 9:44 AM Paul Smith wrote: > > On Sun, 2019-09-01 at 15:33 -0400, Dmitry Goncharov via Bug reports and > discussion for GNU make wrote: > > This patch executes posix_spawnp at configuration time and then > >

Re: gmake-4.2.90 patch

t; 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 96) # define _GL_ATTRIBUTE_PURE __attribute__ ((__pure__)) #else # define _GL_ATTRIBUTE_PURE /* empty */ #endif /* The __const__ attribute was added in gcc 2.95. */ #if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95) # defin

gmake-4.2.90 regression (segmentation fault in sum_up_to_nul )

Good morning. sum_up_to_nul reads 4 bytes starting from the passed string 'p'. 'p' can have fewer than 4 bytes. Usually there more allocated space after 'p', which prevents this reading from manifesting itself. This reading manifests itself visibly when 'p' points to the end of the allocated

gmake-4.2.90 patch

This patch fixes a compilation error when time.h does not get indirectly included. regards, Dmitry diff --git a/src/file.c b/src/file.c index c20fcf8..f58e855 100644 --- a/src/file.c +++ b/src/file.c @@ -17,6 +17,7 @@ this program. If not, see . */ #include

gmake-4.2.90 still crashes on $(wildcard hello*/)

$ echo 'all: ; @echo $(wildcard hello*/)' > /tmp/1.mk $ ./make -f /tmp/1.mk Segmentation Fault A patch was provided here https://lists.gnu.org/archive/html/bug-make/2017-12/msg6.html Any chance to have this applied for 4.3? regards, Dmitry ___

gmake-4.2.90 regression (error message missing)

Good morning. Certian implementations of posix_spawn return 0 on failure and then exit the child process with 127. I observed this with older glibc (2.12) and on aix. This results in gmake not printing related error message "no such file" or "permission denied" when the command is missing or not

Re: [bug #56484] [RFE] compile modified files first

On Wed, Jun 12, 2019 at 05:07:41PM -0400, anonymous wrote: > > Problem: if a project has 300 C files and a single header that's included > everywhere, and then someone changes 2 files: the header and any C file, most > likely one wants to know whether the changes caused build errors. However, >

Re: Handling posix_spawn for non-existent binaries

On Wed, Jul 17, 2019 at 12:38 PM Paul Smith wrote: ... > The only idea I have so far is to try to detect when this situation > occurs (by looking for the 127 exit status) then using stat() to check > to see if the binary exists (I suppose I need to check for executable > status) and generating

[PATCH] add wildcard tests

These are wildcard tests that pass patterns with trailing slash. These tests verify the glob patch sent in a separate email. regards, Dmitry diff --git a/tests/run_make_tests.pl b/tests/run_make_tests.pl index cd8a643..99d56bc 100644 --- a/tests/run_make_tests.pl +++ b/tests/run_make_tests.pl @@

[dgoncha...@users.sf.net: [PATCH] use own copy of glob.c]

glibc's glob.c currently does not handle patterns with a trailing slash correctly. https://sourceware.org/bugzilla/show_bug.cgi?id=22513. This patch switches to gmake's own implementaion of glob until glibc is fixed. Once glibc is fixed a version check can be added. If the tests patch submitted

[PATCH] fix wildcard when pattern has a trailing slash.

If patterns has a trailing slash then glob has to match directories only. If the pattern is only 2 characters long (e.g. */) glob already matches directories only. If the pattern is longer e.g. hello*/ then glob matches only directories or files and directoires depending on type in

[dgoncha...@users.sf.net: [PATCH] uninitialized variable in parse_file_seq]

glob/glob.c touches this variable when the user passes a pattern with a trailing slash to wildcard. regards, Dmitry diff --git a/src/read.c b/src/read.c index db1a42d..2e44d5e 100644 --- a/src/read.c +++ b/src/read.c @@ -3065,6 +3065,7 @@ parse_file_seq (char **stringp, unsigned int size, int

<    2   3   4   5   6   7