Re: embedded newlines in shell function variable expansion

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Fri, Oct 9, 2020 at 11:11 AM Byrnes, Robert  wrote:
>
> If I use this Makefile ...
>
> 
> bash$ cat Makefile
> FOO := $(shell echo $(ENTRIES) ; )
> BAR := $(shell echo $(ENTRIES)   )
>
> all:
> @echo FOO = $(FOO)
> @echo BAR = $(BAR)
>
> .PHONY: all
> 
>
> ... and set ENTRIES with embedded newlines, then this happens:
>
> 
> bash$ make 'ENTRIES=
> blartz
> blurfl
> '
> FOO = blartzblurfl
> BAR = blartz blurfl
> 


Good morning.

i opened
https://savannah.gnu.org/bugs/index.php?59247
and attached a patch.
Thanks for your report and the example.

regards, Dmitry

[bug #59247] function shell eats a newline

[Dmitry Goncharov]

Follow-up Comment #1, bug #59247 (project make):

The patch in the attachment fixes the issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59247] function shell eats a newline

[Dmitry Goncharov]

Additional Item Attachment, bug #59247 (project make):

File name: sv_59247_func_shell_eats_newline.diff Size:1 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59247] function shell eats a newline

[Dmitry Goncharov]

URL:
  

 Summary: function shell eats a newline
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 10 Oct 2020 06:24:33 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

A user reported a bug here

https://lists.gnu.org/archive/html/bug-make/2020-10/msg00016.html.

From:   Byrnes, Robert
Subject:embedded newlines in shell function variable expansion
Date:   Fri, 9 Oct 2020 15:03:24 +

If I use this Makefile ...


bash$ cat Makefile
FOO := $(shell echo $(ENTRIES) ; )
BAR := $(shell echo $(ENTRIES)   )

all:
@echo FOO = $(FOO)
@echo BAR = $(BAR)

.PHONY: all


... and set ENTRIES with embedded newlines, then this happens:


bash$ make 'ENTRIES=
blartz
blurfl
'
FOO = blartzblurfl
BAR = blartz blurfl





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

URL:
  

 Summary: Conditional assigment of a target specific variable
prevents export
 Project: make
Submitted by: dgoncharov
Submitted on: Tue 06 Oct 2020 10:38:50 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

I user reported a bug here

https://lists.gnu.org/archive/html/bug-make/2020-10/msg1.html


Hi,

I just got a build failure in lz4.  I've isolated it and made a minimal test 
case, see below.

This is on GNU Guix on a x86_64 machine.

The reason is that apparently one Makefile rule can unwittingly change how 
another unrelated rule functions, IF a submake is involved.

To reproduce:

$ cat Makefile 

all:
$(MAKE) -C foo all

dummy: CFLAGS ?= bar
dummy:

$ cat foo/Makefile 

CFLAGS ?= internal

all:
echo $(CFLAGS)

Expected behavior:

$ CFLAGS=ok make
make -C foo all
make[1]: Entering directory 'foo'
echo ok
ok
make[1]: Leaving directory 'foo'

Actual behavior:

$ CFLAGS=ok make
make -C foo all
make[1]: Entering directory 'foo'
echo internal
internal
make[1]: Leaving directory 'foo'

BR,
   Danny Milosavljevic




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

Follow-up Comment #3, bug #59230 (project make):

That is assignment of a global variable prevents export of a target specific
variable.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

Additional Item Attachment, bug #59230 (project make):

File name:
sv59230_assignment_of_a_global_variable_prevents_export_of_a_target_specific_variable.diff
Size:1 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

Follow-up Comment #4, bug #59230 (project make):

The second patch fixes this second issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

Follow-up Comment #1, bug #59230 (project make):

The attached patch fixes the issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

Follow-up Comment #2, bug #59230 (project make):

However, the following example still fails, even with the attached patch
applied.

$ cat makefile
all:; @echo hello=$$hello
hello=sun
dummy: hello?=world

$ hello=moon  make
hello=



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

Additional Item Attachment, bug #59230 (project make):

File name: sv59230_conditional_assignment_of_a_target_var Size:1 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: GNU Make 4.3: Makefile rule spooky action at a distance

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Sun, Oct 4, 2020 at 9:32 AM Danny Milosavljevic
 wrote:
> I just got a build failure in lz4.  I've isolated it and made a minimal test 
> case, see below.
...

I opened
https://savannah.gnu.org/bugs/index.php?59230
and attached 2 patches which fix this issue that you observed and a
similar issue.
Thanks for your report and the minimal example.

regards, Dmitry

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Dmitry Goncharov]

Follow-up Comment #5, bug #59093 (project make):

The only issue i encountered with make children inheriting a high value of
RLIMIT_STACK was a 32 bit compiler running out of heap when compiling a large
file.

i attached another patch.
This patch sets stack limit to a default hardcoded value when posix_spawn is
enabled. The default is 128Mb. This deprives a 32 bit compiler of 128 Mb out
of its ~2Gb of space.

For those (if any) makefiles which need more than 128Mb of stack we can
introduce 2 new make functions "setrlimit" and "getrlimit". The makefile could
then call "setrlimit". This will relieve the users from the crash and from
having to know the reason of the crash.
Paul, if you think we should add "setrlimit" and "getrlimit" functions please
let me know, i'll submit a patch.


> If the user invokes make and the stack size they specify is too small then
maybe they should increase the stack size before invoking make (they can do
this with ulimit -s before invoking make).

The user won't know what causes the crash.


> Alternatively, maybe it's possible for make to dynamically reset the stack
limit before invoking posix_spawn().

make would have to know the amount of stack occupied to set this smaller
limit.
Also, what to do is this occupied amount is large?


> I don't see any good way to avoid function calls being recursive 

Another option is to keep recursion, but rewrite the code to allow tail call
optimization.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Dmitry Goncharov]

Additional Item Attachment, bug #59093 (project make):

File name: defss.diff Size:2 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Dmitry Goncharov]

Follow-up Comment #2, bug #59093 (project make):

This patch in the attachment solves the issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Dmitry Goncharov]

Additional Item Attachment, bug #59093 (project make):

File name: sv59093_set_stack_size.diffSize:0 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Dmitry Goncharov]

Follow-up Comment #1, bug #59093 (project make):

This is caused by stack overflow.
A change introduced in commit 4f3a41c60a02f6df9fc0725698ade64825907822
prevents setting stack size if posix_spawn is used.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59096] The built in rule for archives fails on aix.

[Dmitry Goncharov]

Follow-up Comment #1, bug #59096 (project make):

This is a patch which fixes this rule.

diff --git a/src/default.c b/src/default.c
index 751ea15..7d31355 100644
--- a/src/default.c
+++ b/src/default.c
@@ -71,6 +71,9 @@ static struct pspec default_pattern_rules[] =

 #else
 { "(%)", "%",
+#ifdef _AIX
+"OBJECT_MODE=any "
+#endif
 "$(AR) $(ARFLAGS) $@ $<" },
 #endif
 /* The X.out rules are only in BSD's default set because


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #59096] The built in rule for archives fails on aix.

[Dmitry Goncharov]

URL:
  

 Summary: The built in rule for archives fails on aix.
 Project: make
Submitted by: dgoncharov
Submitted on: Чт 10 сен 2020 23:40:31
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

$ cat makefile
all: libhello.a(a.o)
%.o: %.c
$(CC) -c -maix64 $<
a.c:
echo 'static int a;' >$@
$
$ make
gcc -c -maix64 a.c
ar rv libhello.a a.o
ar: Creating an archive file libhello.a.
a - a.o
ar: 0707-126 a.o is not valid with the current object file mode.
Use the -X option to specify the desired object mode.
: recipe for target 'libhello.a(a.o)' failed
make: *** [libhello.a(a.o)] Error 1
rm a.o
$

Aix ar requires an option to specify the object file format.

Quote from
https://www.ibm.com/support/knowledgecenter/ssw_aix_72/a_commands/ar.html


"-X modeSpecifies the type of object file ar should examine. The mode 
must be
one of the following:
32
Processes only 32-bit object files
64
Processes only 64-bit object files
32_64
Processes both 32-bit and 64-bit object files
d64
Examines discontinued 64-bit XCOFF files (magic number == U803XTOCMAGIC).
any
Processes all of the supported object files.
The default is to process 32-bit object files (ignore 64-bit objects). The
mode can also be set with the OBJECT_MODE environment variable. For example,
OBJECT_MODE=64 causes ar to process any 64-bit objects and ignore 32-bit
objects. The -X flag overrides the OBJECT_MODE variable."






___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #58979] Recursive make using jobserver hangs at completion

[Dmitry Goncharov]

Follow-up Comment #11, bug #58979 (project make):

> but I have never put '+' on any recipes.  When is that needed?

'+' cause make to keep the jobserver pipe fd open on exec of that command and
also run the command regardless of -n, -p, -q.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #58979] Recursive make using jobserver hangs at completion

[Dmitry Goncharov]

Follow-up Comment #10, bug #58979 (project make):

> No. It did not hang.

-n causes make to run only recursive commands. And the hang does not reproduce
with -n. Which makes us suspect all the other (not recursive) commands.

There are atleast the following debugging options.

Remove recipies one by one until the hang is gone.

or

1. Add logging to jobserver_setup to print the pipe fd.
2. Add a sleep in makefile at the very beginning to give you time to run
auditctl.
3. Run make and see which fds are allocated for the pipe.
4. Run auditctl to see all processes which open your pipe, write to your pipe,
read from your pipe.

or

1. Add logging to jobserver_setup to print the pipe fd.
2. Add a sleep in makefile at the very beginning.
3. Run make and see which pid it has.
4. See in /proc//fd/ the pipe id. It'll look like
$ ls -l /proc/92678/fd/5
lr-x-- 1 dgoncharov who 64 Aug 25 17:46 /proc/92678/fd/5 ->
pipe:[97436149]. Notice pipe id. In this case 97436149.
5. Run lsof |grep  repeately in a loop and redirect the output to a
file. It'll look like
$ lsof |grep -- '97436149 pipe'
make   92678 dgoncharov5r FIFO0,8   0t0
97436149 pipe
sleep  92679 dgoncharov1w FIFO0,8   0t0
97436149 pipe
sleep  92679 dgoncharov5r FIFO0,8   0t0
97436149 pipe

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #58979] Recursive make using jobserver hangs at completion

[Dmitry Goncharov]

Follow-up Comment #8, bug #58979 (project make):

> I've attached my makefiles.

i guess, a clarification is needed.

The attached makefiles are a part of a bigger system. The other part is
missing. It is not possible to reproduce the issue with the attached makefiles
for anyone who is missing the other part.

Can you write the smallest possible makefile (or a set of makefiles), such
that even people who don't have your full build environment can run to
reproduce the issue?


> Per your suggestion, I ran with '-n.'  It revealed nothing interesting. 

Did it hang or not?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58979] Recursive make using jobserver hangs at completion

[Dmitry Goncharov]

Follow-up Comment #3, bug #58979 (project make):

David, can you please attach the makefiles which reproduce the issue?

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #58961] Document dynamic phony targets.

[Dmitry Goncharov]

Follow-up Comment #1, bug #58961 (project make):

Please use the latest attached file.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58961] Document dynamic phony targets.

[Dmitry Goncharov]

Additional Item Attachment, bug #58961 (project make):

File name: doc_dynamic_phony_targets.diff Size:1 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58961] Document dynamic phony targets.

[Dmitry Goncharov]

URL:
  

 Summary: Document dynamic phony targets.
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 15 Aug 2020 02:44:41 PM UTC
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Document dynamic phony targets.

diff --git a/doc/make.texi b/doc/make.texi
index 21573c0..a8aa3a2 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -2829,6 +2829,28 @@ cleandiff :
 rm *.diff
 @end example
 
+.PHONY works with prerequisites statically defined in the makefile.
+Declaring a target that changes depending on user input or some other
external
+condition as a prerequisites of .PHONY will not achieve the desired effect.
+
+@example
+print-%:
+   @@echo $* = $($*)
+@end example
+
+This rule will print the value of a variable specified by the user on the
+command line.
+
+If you say @samp{make print-OBJ}, make will print the value of variable
@var{obj}.
+However, if there is a file called print-OBJ in the current directory, then
this
+rule will not be executed.
+
+Declaring @samp{print-%} a prerequisite of .PHONY will not work, because
when
+you say @samp{make print-OBJ} the target is @samp{print-OBJ}, not
+@samp{print-%}.
+
+You can force such target. @xref{Force Targets}.
+
 @node Force Targets, Empty Targets, Phony Targets, Rules
 @section Rules without Recipes or Prerequisites
 @cindex force targets




___

File Attachments:


---
Date: Sat 15 Aug 2020 02:44:41 PM UTC  Name: doc_dynamic_phony_targets.diff 
Size: 1KiB   By: dgoncharov



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58960] Fix a typo in the manual

[Dmitry Goncharov]

URL:
  

 Summary: Fix a typo in the manual
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 15 Aug 2020 02:42:53 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Fix a typo in the manual.

diff --git a/doc/make.texi b/doc/make.texi
index 21573c0..cc35c59 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -11795,7 +11795,7 @@ control characters are not emitted so that they don't
corrupt log
 files, etc.
 
 The @code{--output-sync} (@pxref{Parallel Output, ,Output During
-Parallel Output}) option will defeat the terminal detection.  When
+Parallel Execution}) option will defeat the terminal detection.  When
 output synchronization is enabled GNU @code{make} arranges for all
 command output to be written to a file, so that its output can be
 written as a block without interference from other commands.  This




___

File Attachments:


---
Date: Sat 15 Aug 2020 02:42:53 PM UTC  Name: doc_sync_out_typo.diff  Size:
626B   By: dgoncharov



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58734] gmake does not check for the existence of a file before complaining it is missing

[Dmitry Goncharov]

Follow-up Comment #1, bug #58734 (project make):

Can you please attach a makefile that demonstrates the issue?

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

Re: export vs $(origin )

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Thu, Jul 2, 2020 at 11:22 AM Jan Beulich  wrote:
> Not according to my observations.

You are right.

regards, Dmitry

Re: export vs $(origin )

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Thu, Jul 2, 2020 at 8:49 AM Jan Beulich  wrote:
> is it really intended for "export"
> without any assignment done at the same time to change the origin of a
> previously undefined variable from "undefined" to "file"?

"export" without any assignment done at the same time sets the origin
to "environment".

export wom
introduces the variable to the env and set origin to environment.

export wom=
also assigns the value of the variable and sets the origin to "file".


> It doesn't
> change "default" to "file" for a variable with a default value, for
> comparison.

export CC=
sets origin to "file" because a new value from the file is assigned.

export CC
keeps origin intact because the value does not change.



> As to the use case - to be able to determine whether a variable has
> been given a non-default value, and for such a check to be independent
> of whether
> - -R was passed to make
> - export lives ahead or after the check
> a change in behavior would seem to be needed, as such a check can,
> afaict, only sensibly check for "undefined" and "default".

Can you post a sample makefile which demonstrates what you want to achieve?

regards, Dmitry

Re: make4.3/make4.2.1 - solaris 11 x86 issues

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Mon, Jun 29, 2020 at 11:20 AM Paul Smith  wrote:
> Unfortunately, Dmitry has been so active with help that I'm not able to
> accept any more of his patches until/unless some sort of copyright
> assignment is executed.  That process was definitely begun but I
> haven't heard anything about it for quite a while now.  Hopefully no
> one is waiting for me to do something!!!

It took some time to obtain a written disclaimer from my employer that
they do not claim any copyright.
Since then I have written to Craig twice already. Waiting for response.
Paul, if you can expedite this process that would be good.

regards, Dmitry

Re: simple assignment of target-specific variables

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Tue, Jun 09, 2020 at 09:36:43AM -0700, David Boyce wrote:

> On Tue, Jun 9, 2020 at 9:21 AM Dmitry Goncharov 
> wrote:
> > You mean for target specific simple variable memory is allocated and
> > the variable is initialized only if the target is built, right?

> Yes, that's the suggestion I was making though I don't know the innards of
> make well enough to know how hard it would be.


After further thinking i came to the following example.

a:=1
bat: wom:=$(a)
a:=2

bat:; @echo wom=$(wom)


If make postpones initialization of wom until bat recipe has to run then the
value of wom will be 2. This would be a breaking change.

regards, Dmitry

[bug #58529] MAKEOVERRIDES does not change the origin

[Dmitry Goncharov]

Follow-up Comment #2, bug #58529 (project make):

make manual specifies that the only thing legal to do with MAKEOVERRIDES is to
reset it.
Why do you want to set new contents of MAKEOVERRIDES? MAKEOVERRIDES is not
intended for this use.
You can override a variable using override.
override FOO=z


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58639] Shortest stem not matched

[Dmitry Goncharov]

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 to build a given file only
if there is a
 target pattern that matches the file name, @emph{and} all
 prerequisites in that rule either exist or can be built.  The rules
 you write take precedence over those that are built in. Note however,
-that a rule whose prerequisites actually exist or are mentioned always
-takes priority over a rule with prerequisites that must be made by
-chaining other implicit rules.
+that a rule whose prerequisites actually exist or are mentioned or
+which has no prerequisites always takes priority over a rule with
+prerequisites that must be made by chaining other implicit rules.
 
 @cindex stem, shortest
 It is possible that more than one pattern rule will meet these


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: simple assignment of target-specific variables

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 target is built or not built, the target-specific variable is needed or 
> not.

You mean for target specific simple variable memory is allocated and
the variable is initialized only if the target is built, right?
Looks reasonable to me.

regards, Dmitry

Re: simple assignment of target-specific variables

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 price with
ifeq ($(findstring aa,$(MAKECMDGOALS)),aa)
dt:=$(shell set -x; date)
endif

regards, Dmitry

Re: simple assignment of target-specific variables

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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: at := $(shell set -x; date)
$(shell sleep 5)
bb: at := $(shell set -x; date)
aa bb:
@:$(info Making $@ at $(at))
$ make
+ date
+ date
Making aa at Tue Jun  9 11:50:08 EDT 2020
Making bb at Tue Jun  9 11:50:13 EDT 2020

Note, aa's at is 5 seconds earlier then bb's.


> But in a target-specific context should the variable be considered "defined" 
> at the time it's parsed or at the time it's needed?
There could be multiple places where it is needed.

regards, Dmitry

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

[Dmitry Goncharov]

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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

Follow-up Comment #1, bug #58497 (project make):

Attached another fix along with new tests.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58435] make 4.3 is not c89 compliant

[Dmitry Goncharov]

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 strerror()

* bootstrap.conf: Add strerror module
* configure.ac: Remove strerror check
* src/misc.c: Remove local strerror() implementation
* src/config.ami.template: Remove HAVE_STRERROR
* src/config.h-vms.template: Ditto.
* src/config.h.W32.template: Ditto.


Either c90 conformance has to be dropped or code from gnulib cannot be easily
integrated.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

Follow-up Comment #1, bug #58365 (project make):

Can you please attach a makefile which reproduces the crash?

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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
+++ b/tests/scripts/features/include
@@ -260,4 +260,15 @@ inc1:; @%s $@ && echo FOO := bar > $@
 rmfiles('inc1');
 }
 
+# Stop when cannot include a makefile.
+# https://savannah.gnu.org/bugs/?56301.
+unlink('inc_a.mk');
+unlink('inc_b.mk');
+run_make_test(q!
+all:; @echo hello
+include inc_a.mk
+-include inc_b.mk
+%_a.mk %_b.mk:; @false
+!, '', "#MAKE#: Failed to remake makefile 'inc_a.mk'.", 512);
+
 1;


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

Follow-up Comment #3, bug #56301 (project make):

These patches are against the current master
(0c326a66c9eb3a3b5e4ab7892578b016b0590b1f).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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:
sv_55242_let_included_files_be_byproduct_of_unrelated_rules_test.diff Size:0
KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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 := bar > $@
 rmfiles('inc1');
 }
 
+unlink('b');
+unlink('a.mk');
+run_make_test(q!
+all:; @echo hello=$(hello)
+include a.mk
+a.mk: b
+b:
+   @echo hello=world >a.mk
+!, '', 'hello=world');
+unlink('a.mk');
+unlink('b');
+
 1;


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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
--- a/src/remake.c
+++ b/src/remake.c
@@ -175,24 +175,30 @@ update_goal_chain (struct goaldep *goaldeps)
 }
   else
 {
-  FILE_TIMESTAMP mtime = MTIME (file);
+  struct file *oldfile = file;
   check_renamed (file);
 
-  if (file->updated && g->changed &&
-   mtime != file->mtime_before_update)
+  if (file->updated && g->changed)
 {
-  /* Updating was done.  If this is a makefile and
- just_print_flag or question_flag is set
(meaning
- -n or -q was given and this file was specified
- as a command-line target), don't change STATUS.
- If STATUS is changed, we will get re-exec'd,
and
- enter an infinite loop.  */
-  if (!rebuilding_makefiles
-  || (!just_print_flag && !question_flag))
-status = us_success;
-  if (rebuilding_makefiles && file->dontcare)
-/* This is a default makefile; stop remaking. 
*/
-stop = 1;
+  FILE_TIMESTAMP lm = oldfile->last_mtime;
+  FILE_TIMESTAMP mtime =
+lm == UNKNOWN_MTIME || lm == NONEXISTENT_MTIME ?
+f_mtime (oldfile, 0) : lm;
+  if (mtime != file->mtime_before_update)
+{
+  /* Updating was done.  If this is a makefile
and
+ just_print_flag or question_flag is set
(meaning
+ -n or -q was given and this file was
specified
+ as a command-line target), don't change
STATUS.
+ If STATUS is changed, we will get re-exec'd,
and
+ enter an infinite loop.  */
+  if (!rebuilding_makefiles
+  || (!just_print_flag && !question_flag))
+status = us_success;
+  if (rebuilding_makefiles && file->dontcare)
+/* This is a default makefile; stop remaking.
 */
+stop = 1;
+}
 }
 }
 }


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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 := bar > $@
 rmfiles('inc1');
 }
 
+# Stop when cannot include a makefile.
+# https://savannah.gnu.org/bugs/?56301.
+run_make_test(q!
+all:; @echo hello
+include inc_a.mk
+-include inc_b.mk
+%_a.mk %_b.mk:; @false
+!, '', "#MAKE#: Failed to remake makefile 'inc_a.mk'.", 512);
+
 1;


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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
&& mtime != makefile_mtimes[i]);
 makefile_status = MAKE_FAILURE;
+if (!keep_going_flag)
+  any_failed = 1;
   }
   }
 else


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: make-4.3: wildcard test #9 fails

[Dmitry Goncharov via Bug reports and discussion for GNU make]

> 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.
https://lists.gnu.org/archive/html/bug-gnulib/2020-04/msg8.html.

On Sun, Apr 05, 2020 at 11:07:31AM -0400, Paul Smith wrote:
> I have on my list to tackle this issue but it's daunting.
That would be good if the fix cited above was applied before you sync with
gnulib.

regards, Dmitry

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

[Dmitry Goncharov]

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 rebuilds all prerequisites that are out of date. If,
during this traverse, make finds out that some prerequisite was out of date,
then make proceeds to rebuild intermediate prerequisites.

Intermediate prerequisites are not rebuild during this traverse along with
prerequisites because, if all prerequisites are up to date then the target is
up to date and there is no need to built intermediate prerequisites.

In your example
foo_A is an intermediary prerequisite.
foo_B is a prerequisite.

2. Another reason is to allow parallel execution. If all prerequisites had to
be built in the specified order how would you built them in parallel?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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
directory' the question arises which other messages should .SILENT suppress?
e.g. if the directory is not executable make prints "permission denied".
Should "permission denied" be suppressed? What about $(warning ) messages, "is
up to date" messages, etc?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

Follow-up Comment #1, bug #58013 (project make):

This is intentional.
See https://savannah.gnu.org/bugs/?54740.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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 >hello.mk)
+include hello.mk
+default:; @echo $(hello)
+!,
+  '', "world\n");
+
+unlink('hello.mk');
+


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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
+++ b/src/makeint.h
@@ -566,6 +566,8 @@ void print_dir_data_base (void);
 void dir_setup_glob (glob_t *);
 void hash_init_directories (void);
 
+FILE_TIMESTAMP name_mtime (const char *name);
+
 void define_default_variables (void);
 void undefine_default_variables (void);
 void set_default_suffixes (void);
diff --git a/src/read.c b/src/read.c
index db52a55..84e9f97 100644
--- a/src/read.c
+++ b/src/read.c
@@ -417,6 +417,10 @@ eval_makefile (const char *filename, unsigned short
flags)
 
   /* Success; clear errno.  */
   deps->error = 0;
+  /* Managed to read the file. Update mtime, if needed.
+ https://savannah.gnu.org/bugs/?57676.  */
+  if (deps->file->last_mtime == NONEXISTENT_MTIME)
+deps->file->last_mtime = name_mtime(deps->file->name);
 
   /* Avoid leaking the makefile to children.  */
   fd_noinherit (fileno (ebuf.fp));
diff --git a/src/remake.c b/src/remake.c
index fb237c5..956ca4c 100644
--- a/src/remake.c
+++ b/src/remake.c
@@ -67,7 +67,6 @@ static enum update_status check_dep (struct file *file,
unsigned int depth,
  FILE_TIMESTAMP this_mtime, int
*must_make);
 static enum update_status touch_file (struct file *file);
 static void remake_file (struct file *file);
-static FILE_TIMESTAMP name_mtime (const char *name);
 static const char *library_search (const char *lib, FILE_TIMESTAMP
*mtime_ptr);
 
 
@@ -1462,7 +1461,7 @@ f_mtime (struct file *file, int search)
This causes one duplicate stat() when -L is being used, but the code is
much cleaner.  */
 
-static FILE_TIMESTAMP
+FILE_TIMESTAMP
 name_mtime (const char *name)
 {
   FILE_TIMESTAMP mtime;


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 for me with make-4.2.1 or make-4.3.90.
Can you try make-4.3?

regards, Dmitry

[bug #57962] apparent regression involving PATH resolution

[Dmitry Goncharov]

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 via Savannah
  https://savannah.gnu.org/

[bug #57962] apparent regression involving PATH resolution

[Dmitry Goncharov]

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 b/lib/findprog-in.c
index c254f2f..d89ec00 100644
--- a/lib/findprog-in.c
+++ b/lib/findprog-in.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "filename.h"
 #include "concat-filename.h"
@@ -190,6 +191,7 @@ find_in_given_path (const char *progname, const char
*path,
   dir = ".";
 
 /* Try all platform-dependent suffixes.  */
+struct stat st;
 for (i = 0; i < sizeof (suffixes) / sizeof (suffixes[0]); i++)
   {
 const char *suffix = suffixes[i];
@@ -208,7 +210,8 @@ find_in_given_path (const char *progname, const char
*path,
use it.  On other systems, let's hope that this program
is not installed setuid or setgid, so that it is ok to
call access() despite its design flaw.  */
-if (eaccess (progpathname, X_OK) == 0)
+if (eaccess (progpathname, X_OK) == 0 &&
+stat(progpathname, &st) == 0 && S_ISREG(st.st_mode))
   {
 /* Found!  */
 if (strcmp (progpathname, progname) == 0)







___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57962] apparent regression involving PATH resolution

[Dmitry Goncharov]

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
  
  
index 91181f4..3e6c3fa 100644 
  
  
--- a/tests/scripts/features/exec 
  
  
+++ b/tests/scripts/features/exec 
  
  
@@ -60,4 +60,20 @@ SHELL = #PERL# 
  
  
 all:; @printf "$(ANSWER)\n"; 
  
  
 !, "ANSWER='$answer'", "$answer\n"); 
  
  
  
  
  
+ 
  
  
+# test 16
  
  
+# Use sh as a shell, but create a directory called 'sh' in PATH. 
  
  
+# https://savannah.gnu.org/bugs/?57962.  
  
  
+mkdir("mybin", 0700);
  
  
+mkdir("mybin/sh", 0700); 
  
  
+run_make_test(q! 
  
  
+SHELL:=sh
  
  
+PATH:=mybin:$(PATH)  
  
  
+all:; @printf "$(ANSWER)\n"  
  
  
+!, "ANSWER='$answer'", "$answer\n"); 
  
  
+ 
  
  
+rmdir("mybin/sh");   
  
  
+rmdir("mybin");  
  
  
+ 
  
  
+ 
  
  
 1;



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: Phony targets not being made

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 be phony. Rules could be implicit.


> Still, it does not explain why marking the addtional rule as PHONY
> changes the result.

There is no such thing as 'marking the addtional rule as PHONY'.
As soon as 'PHONY: $(PHON2)' line is removed rr1-sim is no longer a
phony target and make finds
implicit rule %-sim: % to build this target.

regards, Dmitry

>
> I think the example is valid.
>
> Thanks,
>
> /pedro
>
> > >
> > >

Re: Phony targets not being made

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 rr1-sim done
> .PHONY: $(PHON2)
>
> all: $(PHON1) $(PHON2)
> @echo all done
>
> %-sim: %
> @echo doing $@
>
> $(PHON1):
> @echo doing $@
> --
> The command 'make' gives the output
> doing rr1
> doing rr2
> all done
> Thus rr1-sim is not done.
> The command 'make rr1-sim' gives the output
> make: Nothing to be done for 'rr1-sim'.
> Removing the phony declaration of rr1-sim makes things work as I expect.
> 'make' gives the output
> doing rr1
> doing rr2
> doing rr1-sim
> all done
>
> Is this a bug or is there anything wrong in the Makefile?
>
> Regards
> Christian Paulsen
>
>

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

[Dmitry Goncharov]

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 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Good morning. 
  
  
  
  
  
Stop looking for an included file once found, even if cannot be opened.   
  
  
  
  
  
If the current directory contains a not readable file and an additional
include directory contains a readable file the current file is silently
ignored and the file from the additional include directory is silently
included.
This can come as an unpleasant surprise and is hardly useful.
This behavior contradicts gnu make manual and usual practice in similar
situations.

Gnu make manual explicitly states that lookup continues only if the file is
missing.
Gnu make itself stops looking for a prerequisite file in vpath directories,
once it found one, even if cannot be opened.
Gnu make stops looking for an included file once it found one and the found
one turns out to be corrupt or a directory.
Similarly a compiler stops looking for a header once it found one, even if
cannot be opened.


The change from rmfiles to unlink in features/included is needed to have the
test pass when -keep is specified.

regards, Dmitry




___

File Attachments:


---
Date: Sun 09 Feb 2020 05:07:07 PM UTC  Name: stop_lookup_for_included.diff 
Size: 5KiB   By: dgoncharov



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 that's from an older, not a newer, GNU libc?

That piece of code was from glibc-2.12.
See here
https://sourceware.org/ml/libc-alpha/2016-02/msg00342.html

regards, Dmitry

Re: patch, new test features/exec.

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 report that 4.2.93 passes this test for me with the
default configure settings on linux, sunos and aix, all 64 bit.

regards, Dmitry

make-4.2.93 patch port to c90

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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
+++ b/src/file.c
@@ -641,8 +641,8 @@ struct dep *
 expand_extra_prereqs (const struct variable *extra)
 {
   struct dep *prereqs = extra ? split_prereqs (variable_expand
(extra->value)) : NULL;
-
-  for (struct dep *d = prereqs; d; d = d->next)
+  struct dep *d = prereqs;
+  for (; d; d = d->next)
 {
   d->file = lookup_file (d->name);
   if (!d->file)
diff --git a/src/rule.c b/src/rule.c
index 358ec56..f2e2ac9 100644
--- a/src/rule.c
+++ b/src/rule.c
@@ -72,11 +72,13 @@ snap_implicit_rules (void)
   char *name = NULL;
   size_t namelen = 0;
   struct dep *prereqs = expand_extra_prereqs (lookup_variable
(STRING_SIZE_TUPLE(".EXTRA_PREREQS")));
+  struct dep *d = prereqs;
   unsigned int pre_deps = 0;
+  struct rule *rule = pattern_rules;

   max_pattern_dep_length = 0;

-  for (struct dep *d = prereqs; d; d = d->next)
+  for (; d; d = d->next)
 {
   size_t l = strlen (dep_name (d));
   if (l > max_pattern_dep_length)
@@ -86,17 +88,18 @@ snap_implicit_rules (void)

   num_pattern_rules = max_pattern_targets = max_pattern_deps = 0;

-  for (struct rule *rule = pattern_rules; rule; rule = rule->next)
+  for (; rule; rule = rule->next)
 {
   unsigned int ndeps = pre_deps;
   struct dep *lastdep = NULL;
+  struct dep *dep = rule->deps;

   ++num_pattern_rules;

   if (rule->num > max_pattern_targets)
 max_pattern_targets = rule->num;

-  for (struct dep *dep = rule->deps; dep != 0; dep = dep->next)
+  for (; dep != 0; dep = dep->next)
 {
   const char *dname = dep_name (dep);
   size_t len = strlen (dname);

make-4.2.93 patch enhance error reporting from the test suite

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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, Dmitry



diff --git a/tests/test_driver.pl b/tests/test_driver.pl
index 49c5c0e..a683313 100644
--- a/tests/test_driver.pl
+++ b/tests/test_driver.pl
@@ -237,7 +237,7 @@ sub toplevel
   if (-d $workpath) {
 print "Clearing $workpath...\n";
 &remove_directory_tree("$workpath/")
-or &error ("Couldn't wipe out $workpath\n");
+or &error ("Couldn't wipe out $workpath: $!\n");
   } else {
 mkdir ($workpath, 0777) or &error ("Couldn't mkdir $workpath: $!\n");
   }
@@ -1129,8 +1129,9 @@ sub remove_directory_tree
   -e $targetdir or return 1;

   &remove_directory_tree_inner ("RDT00", $targetdir) or return 0;
-  if ($nuketop) {
-rmdir($targetdir) or return 0;
+  if ($nuketop && !rmdir ($targetdir)) {
+printf "cannot remove $targetdir: $!\n";
+return 0;
   }

   return 1;
@@ -1149,10 +1150,16 @@ sub remove_directory_tree_inner

 lstat ($object);
 if (-d _ && &remove_directory_tree_inner ($subdirhandle, $object)) {
-  rmdir $object or return 0;
+  if (!rmdir $object) {
+printf "cannot remove $object: $!\n";
+return 0;
+  }
 } else {
   if ($^O ne 'VMS') {
-unlink $object or return 0;
+if (!unlink $object) {
+  printf "cannot unlink $object: $!\n";
+  return 0;
+}
   } else {
 # VMS can have multiple versions of a file.
 1 while unlink $object;

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 happens because makeint.h has the following
# if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) || __STRICT_ANSI__
#  define __attribute__(x)

Both -ansi and -std=c99 define __STRICT_ANSI__.

In sys/wait.h wait is declared  as
extern __pid_t wait (__WAIT_STATUS __stat_loc);
and __WAIT_STATUS is defined as

typedef union
  {
union wait *__uptr;
int *__iptr;
  } __WAIT_STATUS __attribute__ ((__transparent_union__));

The above piece of preprocessor code from makeint.h messes up the definition of
__WAIT_STATUS by removing the attribute. Without the attribute wait does not
take int*.

This patch replaces __attribute__ with gmake_attribute to retain the
current behavior of getting __attribute__ removed from gmake's internal
function declartions and keep glibc declarations intact and allow
-std=c99/-ansi.

regards, Dmitry


diff --git a/src/getopt.c b/src/getopt.c
index 35e71ef..5e0f7c2 100644
--- a/src/getopt.c
+++ b/src/getopt.c
@@ -256,7 +256,7 @@ static char *const *original_argv;
 /* Make sure the environment variable bash 2.0 puts in the environment
is valid for the getopt call we must make sure that the ARGV passed
to getopt is that one passed to the process.  */
-static void __attribute__ ((unused))
+static void gmake_attribute ((unused))
 store_args_and_env (int argc, char *const *argv)
 {
   /* XXX This is no good solution.  We should rather copy the args so
diff --git a/src/job.h b/src/job.h
index 812df0d..f052ace 100644
--- a/src/job.h
+++ b/src/job.h
@@ -80,11 +80,11 @@ char **construct_command_argv (char *line, char
**restp, struct file *file,
 pid_t child_execute_job (struct childbase *child, int good_stdin, char **argv);

 #ifdef _AMIGA
-void exec_command (char **argv) __attribute__ ((noreturn));
+void exec_command (char **argv) gmake_attribute ((noreturn));
 #elif defined(__EMX__)
 int exec_command (char **argv, char **envp);
 #else
-void exec_command (char **argv, char **envp) __attribute__ ((noreturn));
+void exec_command (char **argv, char **envp) gmake_attribute ((noreturn));
 #endif

 void unblock_all_sigs (void);
diff --git a/src/main.c b/src/main.c
index 8d18d14..98915ae 100644
--- a/src/main.c
+++ b/src/main.c
@@ -96,7 +96,7 @@ int chdir ();
 #endif
 #ifndef STDC_HEADERS
 # ifndef sun/* Sun has an incorrect decl in a header.  */
-void exit (int) __attribute__ ((noreturn));
+void exit (int) gmake_attribute ((noreturn));
 # endif
 double atof ();
 #endif
diff --git a/src/makeint.h b/src/makeint.h
index 09bfd8c..efc9112 100644
--- a/src/makeint.h
+++ b/src/makeint.h
@@ -220,10 +220,12 @@ extern int vms_legacy_behavior;
 extern int vms_unix_simulation;
 #endif

-#ifndef __attribute__
+#ifndef gmake_attribute
 /* This feature is available in gcc versions 2.5 and later.  */
 # if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) || __STRICT_ANSI__
-#  define __attribute__(x)
+#  define gmake_attribute(x)
+#else
+#  define gmake_attribute(x) __attribute__(x)
 # endif
 /* The __-protected variants of 'format' and 'printf' attributes
are accepted by gcc versions 2.6.4 (effectively 2.7) and later.  */
@@ -232,7 +234,7 @@ extern int vms_unix_simulation;
 #  define __printf__ printf
 # endif
 #endif
-#define UNUSED  __attribute__ ((unused))
+#define UNUSED  gmake_attribute ((unused))

 #if defined (STDC_HEADERS) || defined (__GNU_LIBRARY__)
 # include 
@@ -255,8 +257,8 @@ void *malloc (int);
 void *realloc (void *, int);
 void free (void *);

-void abort (void) __attribute__ ((noreturn));
-void exit (int) __attribute__ ((noreturn));
+void abort (void) gmake_attribute ((noreturn));
+void exit (int) gmake_attribute ((noreturn));
 # endif /* HAVE_STDLIB_H.  */

 #endif /* Standard headers.  */
@@ -486,12 +488,12 @@ typedef struct

 const char *concat (unsigned int, ...);
 void message (int prefix, size_t length, const char *fmt, ...)
-  __attribute__ ((__format__ (__printf__, 3, 4)));
+  gmake_attribute ((__format__ (__printf__, 3, 4)));
 void error (const floc *flocp, size_t length, const char *fmt, ...)
-__attribute__ ((__format__ (__printf__, 3, 4)));
+gmake_attribute ((__format__ (__printf__, 3, 4)));
 void fatal (const floc *flocp, size_t length, const char *fmt, ...)
-__attribute__ ((noreturn, __format__ (__printf__, 3, 4)));
-void out_of_memory () __attribute__((noreturn));
+gmake_attribute ((noreturn, __format__ (__printf__, 3, 4)));
+void out_of_memory () gmake_attribute((noreturn));

 /* When adding macros to this list be sure to update the value of
XGETTEXT_OPTIONS in the po/Makevars file.  */
@@ -509,8 +511,8 @@ void out_of_memory () __attribute__((noreturn));
 #define ONS(_t,_a

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

[Dmitry Goncharov]

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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

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:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

patch, new test features/exec.

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 program which has no shebang on systems where posix_spawn returns 0 and
then fails (bug 57022).  The test also has 13 other tests which pass.
Tested on sunos, linux and aix.

regards, Dmitry


diff --git a/tests/run_make_tests.pl b/tests/run_make_tests.pl
index b36de69..51bf6fe 100644
--- a/tests/run_make_tests.pl
+++ b/tests/run_make_tests.pl
@@ -263,12 +263,13 @@ sub run_make_test
   $answer = subst_make_string($answer);
   }

-  run_make_with_options($makefile, $options, &get_logfile(0),
+  my $result = run_make_with_options($makefile, $options, &get_logfile(0),
 $err_code, $timeout, @call);
   &compare_output($answer, &get_logfile(1));

   $old_makefile = $makefile;
   $makefile = undef;
+  return $result;
 }

 sub add_options {
diff --git a/tests/scripts/features/exec b/tests/scripts/features/exec
new file mode 100644
index 000..7c2ac0e
--- /dev/null
+++ b/tests/scripts/features/exec
@@ -0,0 +1,64 @@
+use warnings;
+use Config;
+
+my $description = "Test that make can execute binaries as well as scripts with"
+ ." various shabangs and without a shebang";
+my $details = "The various shells that this test uses are the default "
+ ."/bin/sh, $origENV{SHELL} and the perl interpreter that is "
+ ." executing this test program. The shells are used for the value"
+ ." of SHELL inside the test makefile and also as a shebang in the"
+ ." executed script. There is also a test which executes a script"
+ ." that has no shebang.";
+
+my $usersh = $origENV{SHELL};
+my $perl = $Config{perlpath};
+my $stem = 'work/features/exec.cmd';
+my $cmd = "$stem";
+my $answer = 'hello, world';
+
+
+# tests [0-11]
+# Have a makefile with various SHELL= exec a shell program with varios
+# shebangs or without a shebang at all.
+my @shebangs = ('', '#!/bin/sh', "#!$usersh", "#!$perl");
+my @shells = ('', 'SHELL=/bin/sh', "SHELL=$usersh");
+my $k = 0;
+for my $shebang (@shebangs) {
+for my $shell (@shells) {
+$cmd = "$stem.$k" if ($k);
+++$k;
+unlink $cmd;
+open(CMD,"> $cmd");
+print CMD "$shebang\n";
+print CMD "printf \"$answer\\n\"\n";
+close(CMD);
+chmod 0700, $cmd;
+
+my $result = &run_make_test(qq!
+$shell
+all:; \@$cmd
+ !, '', "$answer");
+next if $keep;
+next unless $result;
+unlink $cmd;
+}
+}
+
+# tests [12-14]
+# Exec a binary from a makefile that has SHELL=.
+for my $shell (@shells) {
+&run_make_test(qq!
+$shell
+all:; \@$perl -e 'printf "$answer\\n"';
+ !, '', "$answer");
+}
+
+# test 15
+# Use perl as a shell.
+&run_make_test(qq!
+SHELL=$perl
+.SHELLFLAGS=-e
+all:; \@printf "$answer\\n";
+ !, '', "$answer");
+
+1;

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Dmitry Goncharov]

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 does not have a fallback to /bin/sh and the child exits with
127.

The reason dodgy succeeds with SHELL=/bin/bash is gmake spawning /bin/bash and
passing as a parameter to /bin/bash via argv.
The reason dodgy fails with SHELL=/bin/sh is gmake treats SHELL=/bin/sh as if
no shell was explicitly specified in the makefile and again spawns dodgy.

Having configure disable posix_spawn was discussed here
https://lists.gnu.org/archive/html/bug-make/2019-09/msg0.html.

It is possible have gmake always spawn a shell (subject to configure test).
This solution'd cause gmake spawn a shell even when no shell is needed.

Paul, what about replacing --disable-posix-spawn with --enable-posix-spawn?

regards, Dmitry

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 make core.make.1433.1570461665
Reading make
core file header read successfully
Reading ld.so.1
Reading libc.so.1
program terminated by signal SEGV (no mapping at the fault address)
0x7d882098: memcpy%sun4v-hwcap3+0x02a4: ldub [%o1 - 2], %o3
Current function is jhash_string
  467   sum_up_to_nul(b, k, have_nul);
(dbx) where
  [1] memcpy%sun4v-hwcap3(0x7fffc1a0, 0x7d606002,
0xfffd, 0x0, 0x7fffdffe, 0x2), at
0x7d882098
=>[2] jhash_string(k = 0x7d605ffe "8"), line 467 in "hash.c"
  [3] dirfile_hash_1(key = 0x7fffc450), line 416 in "dir.c"
  [4] hash_find_slot(ht = 0x1001882a0, key = 0x7fffc450), line
89 in "hash.c"
  [5] dir_contents_file_exists_p(dir = 0x100188290, filename = (nil)),
line 719 in "dir.c"
  [6] open_dirstream(directory = 0x7fffc860 "subdir"), line
1202 in "dir.c"
  [7] glob_in_dir(pattern = 0x10017f087 "*.c", directory =
0x7fffc860 "subdir", flags = 512, errfunc = (nil), pglob =
0x7fffcc58), line 1299 in "glob.c"
  [8] glob(pattern = 0x10017f080 "subdir/*.c", flags = 512, errfunc =
(nil), pglob = 0x7fffcc58), line 1011 in "glob.c"
  [9] parse_file_seq(stringp = 0x7fffceb0, size = 40U, stopmap
= 257, prefix = (nil), flags = 0), line 3391 in "read.c"
  [10] split_prereqs(p = 0x100184ff0 "subdir/*.c"), line 445 in "file.c"
  [11] record_files(filenames = 0x100185010, are_also_makes = 0,
pattern = (nil), pattern_percent = (nil), depstr = 0x100184ff0
"subdir/*.c", cmds_started = 1U, commands = 0x1001860f0 "",
commands_idx = 0, two_colon = 0, prefix = '\t', flocp =
0x7fffd1d0), line 2006 in "read.c"
  [12] eval(ebuf = 0x7fffd480, set_default = 1), line 875 in "read.c"
  [13] eval_makefile(filename = 0x10017cfee "Makefile", flags = 0),
line 436 in "read.c"
  [14] read_all_makefiles(makefiles = 0x100161320), line 221 in "read.c"
  [15] main(argc = 3, argv = 0x7fffe6c8, envp =
0x7fffe6e8), line 1945 in "main.c"
(dbx) frame 2
Current function is jhash_string
  467   sum_up_to_nul(b, k, have_nul);
(dbx) print k
k = 0x7d605ffe "8"
(dbx) print k+4
k+4 = 0x7d606002 ""


regards, Dmitry

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 fixed in git.
Denis, can you please pull the latest, built, run and report?

regards, Dmitry

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 possible to optimize somewhat (at the expense of source code
simplicity) by having jhash_string take the length of the string from
the caller.
Atleast some of the callers (e.g. file.c) already call strlen.
Or are you concerned with the computation to update klen?

regards, Dmitry

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

It indeed crashes with a core dump. I observed this on sunos/gcc when
p+3 points to the next page.
This should be easy to reproduce with a tool like libefence. Another
way to reproduce is to run $(wildcard hello*) in a directory with
thousands of files.

regards, Dmitry

On Tue, Sep 24, 2019 at 1: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
> > after 'p', which prevents this reading from manifesting itself. This
> > reading manifests itself visibly when 'p' points to the end of the
> > allocated block of memory, such that p + 3 points to not allocated
> > memory.
> > Please have a look at the patch in the attachment.
> > Tested on both big and little endian, 32 and 64 bit.
>
> I understand the issue.  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).
>
> Your subject seems to suggest that you got a coredump: can you clarify
> what system / compiler / etc. that was on?  Although obviously it's
> technically invalid to access beyond the end of a string, it typically
> does work without failure (I see no issues on any of my test systems
> for example), unless you're doing something fancy such as shared memory
> etc. where accessing even one byte beyond a boundary could give a
> segmentation fault.  However, GNU make certainly doesn't do anything
> like that.
>
> With "normal" systems it's safe to read (only) memory beyond the end of
> an array, at least up to the next word size, which is what this code
> does.
>

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: patch, test suite fails to run valgrind

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

patch, test suite fails to run valgrind

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 (features/comments): Command failed: exec: Cannot execute 
valgrind --log-fd=4 --num-callers=15 --tool=memcheck --leak-check=full 
--suppressions=guile.supp /home/dgoncharov/src/gmake/make/tests/../l64/make

This happens because _run_with_timeout attempts to exec an array, while exec 
expects a list.

regards, Dmitry

diff --git a/tests/test_driver.pl b/tests/test_driver.pl
index 1bb98ba..511a43f 100644
--- a/tests/test_driver.pl
+++ b/tests/test_driver.pl
@@ -1008,7 +1008,7 @@ sub _run_with_timeout
   } else {
 my $pid = fork();
 if (! $pid) {
-  exec(@_) or die "exec: Cannot execute $_[0]\n";
+  exec("@_") or die "exec: Cannot execute $_[0]: $!\n";
 }
 local $SIG{ALRM} = sub {
   my $e = $ERRSTACK[0];


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: patch locale settings

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 strict;
use warnings;
perl will tell you that it does not know what POSIX::LC_MESSAGES is.

This patch initializes has_posix right here in test_driver.pl and pulls in 
locale_h.
This patch sets LC_ALL because we saw that LANG has an affect.
This patch won't help those who don't have POSIX.pm (windows?).
I suggest we still set LC_ALL=C in the shell program for systems w/o POSIX.pm.


diff --git a/tests/test_driver.pl b/tests/test_driver.pl
index 4af84da..fb3f0a5 100644
--- a/tests/test_driver.pl
+++ b/tests/test_driver.pl
@@ -60,9 +60,11 @@ $perl_name =~ tr,\\,/,;
 # We want them from the C locale regardless of our current locale.
 
 my $loc = undef;
-if ($has_POSIX) {
-$loc = POSIX::setlocale(POSIX::LC_MESSAGES);
-POSIX::setlocale(POSIX::LC_MESSAGES, 'C');
+my $has_posix = eval { require "POSIX.pm" };
+if ($has_posix) {
+use POSIX 'locale_h';
+$loc = POSIX::setlocale(POSIX::LC_ALL);
+POSIX::setlocale(POSIX::LC_ALL, 'C');
 }
 
 $ERR_no_such_file = undef;
@@ -96,7 +98,7 @@ if (open(my $F, '<', 'file.out')) {
 
 unlink('file.out') or die "Failed to delete file.out: $!\n";
 
-$loc and POSIX::setlocale(POSIX::LC_MESSAGES, $loc);
+$loc and POSIX::setlocale(POSIX::LC_ALL, $loc);
 
 # %makeENV is the cleaned-out environment.
 %makeENV = ();



> Thanks for helping me debug!
Thank you, Paul, for your work on gmake. i'll be glad to help.

regards, Dmitry
> 

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: patch locale settings

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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);
>   POSIX::setlocale(POSIX::LC_MESSAGES, 'C');
>   }
>...get messages...
>   $loc and POSIX::setlocale(POSIX::LC_MESSAGES, $loc);
> 
> So, the question is why does your Perl still provide language-specific
> messages?
has_POSIX is uninitialized at the time test_driver.pl reads it, because
(atleast in my testing) the code which initializes has_POSIX hasn't run yet.

...

> FWIW, I don't want to change the shell script and call that done
> because not everyone invokes the unit tests via the shell script: they
> may invoke it via "perl run_make_tests.pl ..." directly.
Let me come up with a fix for 'perl run_make_tests.pl'.

regards, Dmitry


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: patch out of source builds

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Sat, Sep 14, 2019 at 6:39 PM Paul Smith  wrote:
> Rather, the above comment refers to testing like this:
...
> That is, running the tests from within the remote build directory
> "tests", not from within the source directory "tests".

Thank you. This indeed clarifies it. The purpose of the patch was to
help testing out of source builds.

regards, Dmitry

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: patch locale settings

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 the env variable. The output from gmake is all right.
$ERR_no_such_file is initialized in test_driver.pl on line 75. This
initialization takes place still in the env inherited by the perl
program, before resetENV runs.

i applied this patch
diff --git a/tests/test_driver.pl b/tests/test_driver.pl
index 4af84da..0260357 100644
--- a/tests/test_driver.pl
+++ b/tests/test_driver.pl
@@ -75,2 +75,3 @@ if (open(my $F, '<', 'file.none')) {
 $ERR_no_such_file = "$!";
+print "lc_messages=$ENV{LC_MESSAGES}, set ERR_no_such_file to
$ERR_no_such_file\n";
 }
@@ -172,2 +173,3 @@ sub resetENV
   }
+  print "reset env, lc_messages=$ENV{LC_MESSAGES}\n";
 }

And here are the first 3 lines of output
$ LC_MESSAGES=ru_RU ./run_make_tests -make_path ../l64/make features/errors
lc_messages=ru_RU, set ERR_no_such_file to ??? ?? ? ??? 
reset env, lc_messages=
--

The only question is how the output from the perl program (called
base) is not affected by env variable on your host.
regards, Dmitry

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: patch locale settings

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 environment so that only a set number of
> variables are actually reserved, and LANG is not one of them (nor is
> LC_MESSAGES), so setting LANG in the run_make_tests shell script should
> not have any effect.

LANG and LC_MESSAGES both affect tests on certain hosts.

> I need to understand your failure situation better before applying this
> change.

Paul, i assume the system on which you test can print messages in various
locales. I have a host which cannot do anything other than the default locale.
Tests pass on that host regardless of env variables.

Here is an example from a host which honors env variables
$ export LC_MESSAGES=fr_CA.UTF-8; echo 'all: ; ./asdf' | ../l64/make -f-
./asdf
make: ./asdf: Aucun fichier ou dossier de ce type
make: *** [/tmp/GmvTj9K1;1: all] Error 127

What does
export LC_MESSAGES=fr_CA.UTF-8; echo 'all: ; ./asdf' | ../l64/make -f-
print on your host?

Below are a couple of examples of failures on aix and linux.
These tests pass when LANG and LC_MESSAGES are unset or set to C.

$ LANG=en_US ./run_make_tests -make_path ../i32/make features/errors;
cat work/features/errors.diff.3
--
Running tests for GNU make on AIX 1 00F85A9D4C00
   GNU Make 4.2.90
--

Clearing work...
Making work dirs...

features/errors . FAILED (4/7 passed)

3 Tests in 1 Category Failed (See .diff* files in work dir for details) :-(

*** work/features/errors.base.3 Sat Sep 14 15:16:57 2019
--- work/features/errors.log.3  Sat Sep 14 15:16:57 2019
***
*** 1,3 
  ./foobarbazbozblat xx yy
! make: ./foobarbazbozblat: A file or directory in the path name does not exist.
  make: [work/features/errors.mk.2;2: one] Error 127 (ignored)
--- 1,3 
  ./foobarbazbozblat xx yy
! make: ./foobarbazbozblat: No such file or directory
  make: [work/features/errors.mk.2;2: one] Error 127 (ignored)
$



$ LC_MESSAGES=ru_RU ./run_make_tests -make_path ../l32/make
features/errors; cat work/features/errors.diff.3
--
Running tests for GNU make on Linux 2.6.32-642.6.2.el6.x86_64 x86_64
   GNU Make 4.2.90
--

Clearing work...
Making work dirs...

features/errors . FAILED (4/7 passed)

3 Tests in 1 Category Failed (See .diff* files in work dir for details) :-(

*** work/features/errors.base.3 Sat Sep 14 15:19:22 2019
--- work/features/errors.log.3  Sat Sep 14 15:19:22 2019
***
*** 1,3 
  ./foobarbazbozblat xx yy
! make: ./foobarbazbozblat: ??? ?? ? ??? 
  make: [work/features/errors.mk.2;2: one] Error 127 (ignored)
--- 1,3 
  ./foobarbazbozblat xx yy
! make: ./foobarbazbozblat: No such file or directory
  make: [work/features/errors.mk.2;2: one] Error 127 (ignored)


regards, Dmitry

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: patch out of source builds

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 it.  For example, what happens when
> Make is built using build.sh?  And on MS-Windows the _only_ supported
> build method is by using a script similar to build.sh.

run_make_tests.pl unconditionally reads config.status from a specific location.
If gmake is built out of source this reading fails.  The patch then looks for
config.status in the -make_path directory.  This will help if you have
config.status in the -make_path directory.  If you don't have config.status in
-make_path directory this won't help and won't hurt.  If you don't have
config.status in -make_path directory it will behave the same as today.



regards, Dmitry


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

patch locale settings

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 @@
 #!/bin/sh
+export LC_ALL=C
 exec perl $0.pl ${1+"$@"}

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

patch realpath on aix

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 gmake manual allow this behavior this patch fixes the test
case, even though the behavior is inconsistent between os' and between /tmp/ vs
/tmp//. An alternative could be to make gmake remove the trailing slash.

regards, Dmitry

diff --git a/tests/scripts/functions/realpath b/tests/scripts/functions/realpath
index fcea515..dd7d349 100644
--- a/tests/scripts/functions/realpath
+++ b/tests/scripts/functions/realpath
@@ -13,8 +13,9 @@ ifneq ($(realpath ./),$(CURDIR))
   $(warning $(realpath ./) != $(CURDIR))
 endif

-ifneq ($(realpath .///),$(CURDIR))
-  $(warning $(realpath .///) != $(CURDIR))
+r:=$(patsubst %/,%,$(realpath .///))
+ifneq ($(r),$(CURDIR))
+  $(warning $(r) != $(CURDIR))
 endif

 .PHONY: all

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

patch out of source builds

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 the tests directory for pointers.

 The second serious problem is that it's not parallelizable: it scribbles
 all over its installation directory and so can only test one make at a
-time.  The third serious problem is that it's not relocatable: the only
-way it works when you build out of the source tree is to create
-symlinks, which doesn't work on every system and is bogus to boot.  The
-fourth serious problem is that it doesn't create its own sandbox when
-running tests, so that if a test forgets to clean up after itself that
-can impact future tests.
+time. The third serious problem is that it doesn't create its own
+sandbox when running tests, so that if a test forgets to clean up after
+itself that can impact future tests.


 Bugs
diff --git a/tests/run_make_tests.pl b/tests/run_make_tests.pl
index 7e969a9..437f768 100644
--- a/tests/run_make_tests.pl
+++ b/tests/run_make_tests.pl
@@ -75,12 +75,13 @@ require "test_driver.pl";
 %CONFIG_FLAGS = ();

 my $statnm = "$FindBin::Bin/../config.status";
+my $config_status_errno = "";
 if (open(my $fh, '<', $statnm)) {
 while (my $line = <$fh>) {
 $line =~ m/^[SD]\["([^\"]+)"\]=" *(.*)"/ and $CONFIG_FLAGS{$1} = $2;
 }
 } else {
-warn "Failed to open $statnm: $!";
+$config_status_errno = $!;
 }

 # Some target systems might not have the POSIX module...
@@ -98,6 +99,19 @@ sub valid_option
print "$option $make_path: Not found.\n";
exit 0;
}
+   if ($config_status_errno) {
+   my $dir = File::Basename::dirname("$make_path");
+   $statnm = "$dir/config.status";
+   if (open(my $fh, '<', $statnm)) {
+   while (my $line = <$fh>) {
+   $line =~ m/^[SD]\["([^\"]+)"\]=" *(.*)"/ and
+$CONFIG_FLAGS{$1} = $2;
+   }
+   $config_status_errno = "";
+   } else {
+   $config_status_errno = $!;
+   }
+   }
return 1;
}

@@ -138,6 +152,13 @@ sub valid_option
return 0;
 }

+sub print_failed_to_open_configstatus
+{
+   if ($config_status_errno) {
+   warn "Failed to open $statnm: $config_status_errno";
+   }
+}
+

 # This is an "all-in-one" function.  Arguments are as follows:
 #
diff --git a/tests/test_driver.pl b/tests/test_driver.pl
index 4af84da..e1235ca 100644
--- a/tests/test_driver.pl
+++ b/tests/test_driver.pl
@@ -516,6 +516,7 @@ sub parse_command_line
   push(@TESTS,$option);
 }
   }
+  &print_failed_to_open_configstatus;
 }

 sub max

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: vpathplus test 2 patch

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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?

regards, Dmitry

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

vpathplus test 2 patch

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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
index 8e723fe..3ab9c05 100644
--- a/tests/scripts/features/vpathplus
+++ b/tests/scripts/features/vpathplus
@@ -96,10 +96,12 @@ $make_name: *** [$makefile;13: notarget.b] Error 1

 push(@touchedfiles, "inter.a", "inter.b");

+my $be = pack("L", 1) eq pack("N", 1);
+my $intfiles = $be ? "inter.c inter.b" : "inter.b inter.c";
 $answer = "cat ${VP}inter.d > inter.c
 cat inter.c > inter.b 2>/dev/null || exit 1
 cat inter.b > inter.a
-rm inter.b inter.c
+rm $intfiles
 ";
 &compare_output($answer,&get_logfile(1));

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

patch to fix grouped_targets test 1

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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
--- a/tests/scripts/features/grouped_targets
+++ b/tests/scripts/features/grouped_targets
@@ -9,9 +9,9 @@ $details = "Here we test for requirements like\n"
 run_make_test(q{
 .PHONY: all
 &:;
-all: ;@echo -n
+all: ;@echo foo
 },
-'', "");
+'', "foo");

 # Parsing: &: works not preceded by whitespace.
 run_make_test(q{

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

patch to fix features/archives test 10 on sunos

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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
ar: writing libxx.a

diff --git a/tests/scripts/features/archives b/tests/scripts/features/archives
index 87a5007..16372fa 100644
--- a/tests/scripts/features/archives
+++ b/tests/scripts/features/archives
@@ -221,6 +221,8 @@ if ($osname ne 'VMS') {
 my $lib = 'libxx.a';
 my $cr = $created;
 $cr =~ s#a1\.o#${pre}a#;
+my $a = $add;
+$a  =~ s/#OBJECT#/${pre}b/;

 run_make_test(qq!
 # Both member names > 16 characters long
@@ -230,7 +232,7 @@ default: $lib(${pre}a) $lib(${pre}b)

 $pre%: ; touch \$\@
 !,
-  $arvar, "touch ${pre}a\n$ar $arflags $lib
${pre}a\n${cr}touch ${pre}b\n$ar $arflags $lib ${pre}b\na -
${pre}b\nrm ${pre}a ${pre}b\n");
+  $arvar, "touch ${pre}a\n$ar $arflags $lib
${pre}a\n${cr}touch ${pre}b\n$ar $arflags $lib ${pre}b\n${a}rm ${pre}a
${pre}b\n");

 # Run it again; nothing should happen
 run_make_test(undef, $arvar, "#MAKE#: Nothing to be done for
'default'.\n");

regards, Dmitry

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: gmake-4.2.90 regression (error message missing)

[Dmitry Goncharov via Bug reports and discussion for GNU make]

You were planning to use stat, right? Are you planning to stat the
interperter specified in shebang as well?
Some of the races can be avoided by opening the file before
posix_spawn and then using fstat on the fd.
Alternatively that posix_spawn check from configure.ac can be executed
at runtime 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
> > disables posix_spawn if posix_spawn returns 0 on an attempt to exec a
> > missing file.
> > This solution won't work for cross compilation.
>
> Thanks Dmitry.  I guessed at this issue during testing:
>
> https://lists.gnu.org/archive/html/bug-make/2019-08/msg00063.html
>
> I have a different solution in mind that doesn't require using
> configure tests and won't have issues with cross-compilation: I'm just
> handling the 127 exit code and generating the appropriate error message
> directly.
>

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: gmake-4.2.90 patch

[Dmitry Goncharov via Bug reports and discussion for GNU make]

amp; defined __GNUC_STDC_INLINE__ \
&& ! defined __clang__) \
 : ((! defined _DONT_USE_CTYPE_INLINE_ \
 && (defined __GNUC__ || defined __cplusplus)) \
|| (defined _FORTIFY_SOURCE && 0 < _FORTIFY_SOURCE \
&& defined __GNUC__ && ! defined __cplusplus
# define _GL_EXTERN_INLINE_STDHEADER_BUG
#endif
#if ((__GNUC__ \
  ? defined __GNUC_STDC_INLINE__ && __GNUC_STDC_INLINE__ \
  : (199901L <= __STDC_VERSION__ \
 && !defined __HP_cc \
 && !defined __PGI \
 && !(defined __SUNPRO_C && __STDC__))) \
 && !defined _GL_EXTERN_INLINE_STDHEADER_BUG)
# define _GL_INLINE inline
# define _GL_EXTERN_INLINE extern inline
# define _GL_EXTERN_INLINE_IN_USE
#elif (2 < __GNUC__ + (7 <= __GNUC_MINOR__) && !defined __STRICT_ANSI__ \
   && !defined _GL_EXTERN_INLINE_STDHEADER_BUG)
# if defined __GNUC_GNU_INLINE__ && __GNUC_GNU_INLINE__
   /* __gnu_inline__ suppresses a GCC 4.2 diagnostic.  */
#  define _GL_INLINE extern inline __attribute__ ((__gnu_inline__))
# else
#  define _GL_INLINE extern inline
# endif
# define _GL_EXTERN_INLINE extern
# define _GL_EXTERN_INLINE_IN_USE
#else
# define _GL_INLINE static _GL_UNUSED
# define _GL_EXTERN_INLINE static _GL_UNUSED
#endif

/* In GCC 4.6 (inclusive) to 5.1 (exclusive),
   suppress bogus "no previous prototype for 'FOO'"
   and "no previous declaration for 'FOO'" diagnostics,
   when FOO is an inline function in the header; see
   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54113> and
   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63877>.  */
#if __GNUC__ == 4 && 6 <= __GNUC_MINOR__
# if defined __GNUC_STDC_INLINE__ && __GNUC_STDC_INLINE__
#  define _GL_INLINE_HEADER_CONST_PRAGMA
# else
#  define _GL_INLINE_HEADER_CONST_PRAGMA \
 _Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=const\"")
# endif
# define _GL_INLINE_HEADER_BEGIN \
_Pragma ("GCC diagnostic push") \
_Pragma ("GCC diagnostic ignored \"-Wmissing-prototypes\"") \
_Pragma ("GCC diagnostic ignored \"-Wmissing-declarations\"") \
_GL_INLINE_HEADER_CONST_PRAGMA
# define _GL_INLINE_HEADER_END \
_Pragma ("GCC diagnostic pop")
#else
# define _GL_INLINE_HEADER_BEGIN
# define _GL_INLINE_HEADER_END
#endif

/* Define to `int' if  doesn't define. */
/* #undef gid_t */

/* Work around a bug in Apple GCC 4.0.1 build 5465: In C99 mode, it supports
   the ISO C 99 semantics of 'extern inline' (unlike the GNU C semantics of
   earlier versions), but does not display it by setting __GNUC_STDC_INLINE__.
   __APPLE__ && __MACH__ test for Mac OS X.
   __APPLE_CC__ tests for the Apple compiler and its version.
   __STDC_VERSION__ tests for the C99 mode.  */
#if defined __APPLE__ && defined __MACH__ && __APPLE_CC__ >= 5465 &&
!defined __cplusplus && __STDC_VERSION__ >= 199901L && !defined
__GNUC_STDC_INLINE__
# define __GNUC_STDC_INLINE__ 1
#endif

/* Define to `int' if  does not define. */
/* #undef mode_t */

/* Define to `long int' if  does not define. */
/* #undef off_t */

/* Define to `int' if  does not define. */
/* #undef pid_t */

/* Define to the equivalent of the C99 'restrict' keyword, or to
   nothing if this is not supported.  Do not define if restrict is
   supported directly.  */
#define restrict __restrict
/* Work around a bug in Sun C++: it does not support _Restrict or
   __restrict__, even though the corresponding Sun C compiler ends up with
   "#define restrict _Restrict" or "#define restrict __restrict__" in the
   previous line.  Perhaps some future version of Sun C++ will work with
   restrict; if so, hopefully it defines __RESTRICT like Sun C does.  */
#if defined __SUNPRO_CC && !defined __RESTRICT
# define _Restrict
# define __restrict__
#endif

/* Define to `unsigned int' if  does not define. */
/* #undef size_t */

/* Define to `int' if  does not define. */
/* #undef ssize_t */

/* Define to `int' if  doesn't define. */
/* #undef uid_t */

/* Define to the widest unsigned integer type if  and 
   do not define. */
/* #undef uintmax_t */

/* Define as a marker that can be attached to declarations that might not
be used.  This helps to reduce warnings, such as from
GCC -Wunused-parameter.  */
#if __GNUC__ >= 3 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 7)
# define _GL_UNUSED __attribute__ ((__unused__))
#else
# define _GL_UNUSED
#endif
/* The name _UNUSED_PARAMETER_ is an earlier spelling, although the name
   is a misnomer outside of parameter lists.  */
#define _UNUSED_PARAMETER_ _GL_UNUSED

/* gcc supports the "unused" attribute on possibly unused 

gmake-4.2.90 regression (segmentation fault in sum_up_to_nul )

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 block of memory, such that p + 3 points to not allocated
memory.
Please have a look at the patch in the attachment.
Tested on both big and little endian, 32 and 64 bit.

regards, Dmitry
diff --git a/src/hash.c b/src/hash.c
index bd3892e..67f0018 100644
--- a/src/hash.c
+++ b/src/hash.c
@@ -16,6 +16,7 @@ this program.  If not, see .  */

 #include "makeint.h"
 #include "hash.h"
+#include 

 #define CALLOC(t, n) ((t *) xcalloc (sizeof (t) * (n)))
 #define MALLOC(t, n) ((t *) xmalloc (sizeof (t) * (n)))
@@ -410,10 +411,13 @@ unsigned jhash(unsigned const char *k, int length)

 #ifdef WORDS_BIGENDIAN
 /* The ifs are ordered from the first byte in memory to the last.  */
-#define sum_up_to_nul(r, p, flag) \
+#define sum_up_to_nul(r, p, plen, flag)   \
   do {\
-unsigned int val; \
-memcpy(&val, (p), 4); \
+unsigned int val = 0; \
+size_t vsz = sizeof (val);\
+size_t pn = (plen);   \
+size_t n = pn < vsz ? pn : vsz;   \
+memcpy(&val, (p), n); \
 if ((val & 0xFF00) == 0)  \
   flag = 1;   \
 else if ((val & 0xFF) == 0)   \
@@ -427,11 +431,14 @@ unsigned jhash(unsigned const char *k, int length)
 /* First detect the presence of zeroes.  If there is none, we can
sum the 4 bytes directly.  Otherwise, the ifs are ordered as in the
big endian case, from the first byte in memory to the last.  */
-#define sum_up_to_nul(r, p, flag)   \
+#define sum_up_to_nul(r, p, plen, flag) \
   do {  \
-unsigned int val;   \
+unsigned int val = 0;   \
+size_t vsz = sizeof (val);  \
+size_t pn = (plen); \
+size_t n = pn < vsz ? pn : vsz; \
 unsigned int zeroes;\
-memcpy(&val, (p), 4);   \
+memcpy(&val, (p), n);   \
 zeroes = ((val - 0x01010101) & ~val);   \
 if (!(zeroes & 0x80808080)) \
   r += val; \
@@ -454,24 +461,31 @@ unsigned jhash_string(unsigned const char *k)
   unsigned int a, b, c;
   unsigned int have_nul = 0;
   unsigned const char *start = k;
+  size_t klen = strlen(k);

   /* Set up the internal state */
   a = b = c = JHASH_INITVAL;

   /* All but the last block: affect some 32 bits of (a,b,c) */
   for (;;) {
-sum_up_to_nul(a, k, have_nul);
+sum_up_to_nul(a, k, klen, have_nul);
 if (have_nul)
   break;
 k += 4;
-sum_up_to_nul(b, k, have_nul);
+assert (klen >= 4);
+klen -= 4;
+sum_up_to_nul(b, k, klen, have_nul);
 if (have_nul)
   break;
 k += 4;
-sum_up_to_nul(c, k, have_nul);
+assert (klen >= 4);
+klen -= 4;
+sum_up_to_nul(c, k, klen, have_nul);
 if (have_nul)
   break;
 k += 4;
+assert (klen >= 4);
+klen -= 4;
 jhash_mix(a, b, c);
   }


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

gmake-4.2.90 patch

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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 "makeint.h"

 #include 
+#include 

 #include "filedef.h"
 #include "dep.h"

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

$ 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

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

gmake-4.2.90 regression (error message missing)

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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
executable. This also causes multiple tests to fail.

$ echo 'all: ; @./foo' > /tmp/1.mk
$ ./make-4.2.90  -f /tmp/1.mk
make-4.2.90: *** [/tmp/1.mk;1: all] Error 127
$ ./make.patched  -f /tmp/1.mk
make.patched: ./foo: No such file or directory
make.patched: *** [/tmp/1.mk;1: all] Error 127

This patch executes posix_spawnp at configuration time and then
disables posix_spawn if posix_spawn returns 0 on an attempt to exec a
missing file.
This solution won't work for cross compilation.

regards, Dmitry

index f6919a7..9da113c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -142,7 +142,7 @@ AC_CHECK_FUNCS([strdup strndup umask mkstemp mktemp fdopen \
 dup dup2 getcwd realpath sigsetmask sigaction \
 getgroups seteuid setegid setlinebuf setreuid setregid \
 getrlimit setrlimit setvbuf pipe strsignal \
-lstat readlink atexit isatty ttyname pselect posix_spawn \
+lstat readlink atexit isatty ttyname pselect
posix_spawn posix_spawnp \
 posix_spawnattr_setsigmask])

 # We need to check declarations, not just existence, because on Tru64 this
@@ -368,7 +368,18 @@ AC_ARG_ENABLE([posix-spawn],
 AS_CASE([/$ac_cv_header_spawn/$ac_cv_func_posix_spawn/],
   [*/no/*], [make_cv_posix_spawn=no])

-AS_CASE([/$make_cv_posix_spawn/$user_posix_spawn/],
+AC_RUN_IFELSE(
+   [AC_LANG_PROGRAM([
+#include 
+#include ], [
+char* av[[]] = {"./macarie", '\0'};
+char* envp[[]] = {'\0'};
+return posix_spawnp(0, av[[0]], 0, 0, av, envp) != ENOENT; ])],
+  [posix_spawn_is_good="yes"],
+  [posix_spawn_is_good="no"]
+)
+
+AS_CASE([/$make_cv_posix_spawn/$user_posix_spawn/$posix_spawn_is_good/],
   [*/no/*], [make_cv_posix_spawn=no],
   [AC_DEFINE(USE_POSIX_SPAWN, 1, [Define to 1 to use posix_spawn().])
   ])

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

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,
> after executing `make`, in the worst case, the changed C file may get built
> after the 299 others, and fail the build.
...
>$ touch empty1.c empty2.c header.h && echo "int main() {}" > main.c
...


Tell make which target you are interested in.

$ echo '#include "header.h"' |tee -a  *.c
$ touch header.h
$ make empty1.o
gcc -c empty1.c -o empty1.o
$


regards, Dmitry

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Handling posix_spawn for non-existent binaries

[Dmitry Goncharov]

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 the error on my own.

Subject to a race condition.

regads, Dmitry

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make