Re: [bug #61226] A regression prevents generation of missing included dependency files.

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

On Monday, October 25, 2021, Alejandro Colomar (man-pages) <
alx.manpa...@gmail.com> wrote:

> However, there's a downside to this:  The payment for this robustness is a
> non-negligible time cost.  The single-process time for a no-op make is
> around 10 s


>
>  10s is about 100 to 1000 times longer than what make is capable of.

Regards, Dmitry

Re: [bug #61226] A regression prevents generation of missing included dependency files.

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

On Monday, October 25, 2021, Alejandro Colomar (man-pages) <
alx.manpa...@gmail.com> wrote:
>
>
> Why do I do this?  Because, if you remove a file from your tree, an old .d
> file will require that file and make your build fail, requiring you to
> clean before making again.
>
>

This has been solved long ago. Check the awesome advanced dependency
generation article by Paul.

Regards, Dmitry

Re: [bug #61226] A regression prevents generation of missing included dependency files.

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

On Sun, Oct 17, 2021 at 11:17 PM Britton Kerin  wrote:
> I got that but it sounds like the proposal is for it to do one thing
> if the file is a .d and otherwise something else?

The proposal is to see if the recipe is empty.

There is this statement in the manual
"If a rule has no prerequisites or recipe, and the target of the rule
is a nonexistent file, then make imagines this target to have been
updated whenever its rule is run."
It is not clear how this behavior could be implemented without
checking the recipe.

regards, Dmitry

Re: [bug #61226] A regression prevents generation of missing included dependency files.

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

On Mon, Oct 25, 2021 at 6:12 AM Edward Welbourne  wrote:

> Surely that would solve your problem, without invasive surgery in GNU
> make, or special-case handling of .d files anywhere but your make file ?

Actually, my makefiles do not suffer from this. i use the technique
described here 
https://github.com/dgoncharov/fun/blob/master/autodeps/include_as_part_of_the_dag,
which avoids including .d files.
makefiles which include .d files suffer.


regards, Dmitry

Re: -V, --verbose, as opposite of -s, --silent, --quiet

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

On Fri, Oct 22, 2021 at 9:02 PM Alejandro Colomar (man-pages)
 wrote:
> The output would be something like:
>
> CC  foo.o
> CC  bar.o
> ...
>
> But then, if something goes wrong (e.g., bar.c stops compiling into
> bar.o), I'd like to be able to debug the build by showing the full command.
 Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
> http://www.alejandro-colomar.es/


Good morning.

http://make.mad-scientist.net/managing-recipe-echoing/

regards, Dmitry

Re: [bug #61226] A regression prevents generation of missing included dependency files.

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

On Sun, Oct 17, 2021 at 3:05 PM Britton Kerin  wrote:

> If I understand right that the idea is a special case for .d files

The question being discussed is what to do when make cannot include a makefile.

regards, Dmitry

Re: Make language

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

On Tue, Oct 12, 2021 at 10:38 AM Bartol Hrg  wrote:
>
> Greetings
>
> I installed make 3.81 for Windows
>
> It's in d*mn Croatian!
>
> Now, I don't know if you noticed, but I speak English.
>
> I'm really displeased and agitated.
>
> Best regards
> B. Helium

Dobar dan.
Vaš pošta je na Engleskom jeziku.
Ne znam jeste li primijetili, ali govorim Hrvatski.
Stvarno sam nezadovoljna i uznemirena.

Iskreno, Dmitry

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

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

On Sun, Jul 25, 2021 at 3:25 PM Paul Smith  wrote:
> I have no problem with make refusing to write to a device that's locked
> in general.  If users don't want that to happen, they can just not use
> the -O option.

True, as long as the user knows that when -O is specified make is
going to lock stdout.


> It's clear that /dev/null is a special case, however, because the order
> in which data is written to it cannot be detected so what's the point
> in preserving any order?

Maybe Mike can tell us.


> What I'm saying is that IF make can detect that its stdout is going to
> /dev/null then it shouldn't lock at all, because it's not necessary to
> do so in order to meet the goals of the -O option, and doing so
> introduces unnecessary latency in the build.

Even if we come up with a portable mechanism to detect /dev/null, what
about other files?
What about /dev/stdout or /dev/pts/5?
i don't think, it is possible or even reasonable to attempt to special
case all these files.


> The  question is what to do about supporting -O on these systems.

A private temp file will work.


> That's true but there are, unfortunately, some edge cases where Windows
> and POSIX systems behave differently.

True. Is this case really one of those edge cases?

>  The goal is to provide  the best implementation of make for the GNU system

What do you think we should do about this bug report?

regards, Dmitry

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

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

On Sun, Jul 25, 2021 at 10:03 AM Paul Smith  wrote:
> Writing to
> things like /dev/lp0 SHOULD be locked, IMO: you don't want multiple
> concurrent writers to your printers or your terminal!

The user intentionally redirects make to a printer along with another
tool. Should make be smarter than the user and refuse?
When -O is not specified make will happily run redirected to a printer.


> To me the most compelling reason to change the current locking behavior
> is not this: I agree with David that simply special-casing /dev/null
> could be a good solution; if you're redirecting to /dev/null why even
> HAVE a lock?

Mike wanted to specify -O and redirect to /dev/null. Again, why should
the tool be smarter the user?


> The most compelling reason to change the current behavior is that
> unfortunately BSD-based systems don't support locking file descriptors
> that aren't real files: so if you pipe make's output to something on a
> BSD-based system like MacOS or FreeBSD, for example, you get a ton of
> error messages.

One mechanism to avoid these error messages would be to stat stdout
and check S_IFREG.


> submake: ; $(MAKE) -C $@ >sub.out
>
> The way the implementation is today, the outer make and the submake
> magically have different "output lock domains",

This is an interesting situation.
i considered this behavior to be a violation of the contract. The make
manual says that when -O is specified the output of the parent and
children is synchronized.
make is a portable tool and this magic does not happen on windows.
i think, we should either fix the deadlock or document that make locks
stdout. Otherwise, you see, the users are confused.


regards, Dmitry

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

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

On Sun, Jul 25, 2021 at 3:49 AM Eli Zaretskii  wrote:
>
> Follow-up Comment #8, bug #60774 (project make):
>
> Why did you remove the code which reused the mutex passed from the parent
> Make?

Eli, i don't think i removed any code, other than the global variable
mutex_handle. Atleast, not intentionally.
i moved record_sync_mutex from w32/compat/posixfcn.c to output.c.
Do you think you tell me the function name or file and line number?

regards, Dmitry

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

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

Wanted to test that windows this still works with this change.

So, i followed instructions in README.W32.
Installed mingw gcc. Copied config.h.W32.template to config.h.w32.
Ran build_W32.bat gcc. It fails with

C:\dgoncharov\make>gcc -mthreads -Wall -std=gnu99 -gdwarf-2 -g3 -O2 -DMAKE_MAINT
AINER_MODE -I.\GccRel/src -I./src -I.\GccRel/lib -I./lib -I./src/w32/include -DW
INDOWS32 -DHAVE_CONFIG_H  -o .\GccRel/src/ar.o -c src/ar.c
In file included from src/ar.c:18:
src/makeint.h:314:13: error: conflicting types for 'mode_t'
 typedef int mode_t;
 ^~
In file included from src/makeint.h:86,
 from src/ar.c:18:
c:/Program Files (x86)/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32/i686-
w64-mingw32/include/sys/types.h:77:17: note: previous declaration of 'mode_t' wa
s here  typedef _mode_t mode_t;

Both make and mingw declare mode_t.
More errors like this follow.

Does anyone have a ready to use config.h.W32?


regards, Dmitry

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

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

On Sat, Jul 24, 2021 at 3:02 PM David Boyce  wrote:

> The point is that only /dev/null *should* be shared. Any other file *might* 
> be locked by an unrelated process but that would represent an error condition 
> in which incorrect results should be expected.

i think, it is less likely that an unrelated process locks a make's
private temp file, than a system wide global file.

> I can’t think of a file other than /dev/null which would appropriately be 
> shared with unrelated processes in a “w” (write) condition.

/dev/zero, /dev/lp0, /dev/lp1, /dev/pts, etc.
i recognize the simplicity of using stdout. However, i also dislike
adding pieces of code for a set of special files. The user will always
find a way to screw it.

Also, make is portable. What about those systems which do not have
inode/devices?

regards, Dmitry

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

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

On Saturday, July 24, 2021, David Boyce  wrote:

> Wouldn’t a less intrusive solution be to check the inode/device of stdout
> and if it’s the same as that of /dev/null just forego locking?


That would help this specific case indeed.
What about a case when make's stdout is redirected to another, not dev
null, file? Any file could be locked.

Another case is when a child's stdout is redirected to a file different
from parent.

Regards, Dmitry

>
> > On Jul 24, 2021, at 11:26 AM, Eli Zaretskii 
> wrote:
> >
> > Follow-up Comment #5, bug #60774 (project make):
> >
> > The MS-Windows port of GNU Make doesn't lock stdout (or any other
> standard
> > device).  Instead, it uses a mutex to synchronize output.  So I think
> this
> > problem cannot happen on Windows.
> >
> > But I see that your changeset touches quite a few places in the code
> which is
> > Windows specific, and I wonder why did you have to do that, since the
> problem
> > you are trying to fix doesn't exist there.  Wouldn't it be more prudent
> to
> > leave the Windows-only code alone?
> >
> >
> >___
> >
> > Reply to this item at:
> >
> >  
> >
> > ___
> >  Message sent via Savannah
> >  https://savannah.gnu.org/
> >
> >
>

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

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

On Saturday, July 24, 2021, Eli Zaretskii  wrote:

> Follow-up Comment #5, bug #60774 (project make):
>
> The MS-Windows port of GNU Make doesn't lock stdout (or any other standard
> device).  Instead, it uses a mutex to synchronize output.  So I think this
> problem cannot happen on Windows.


True.

>
> But I see that your changeset touches quite a few places in the code which
> is
> Windows specific, and I wonder why did you have to do that, since the
> problem
> you are trying to fix doesn't exist there.  Wouldn't it be more prudent to
> leave the Windows-only code alone?


The windows code, which passes down the semaphore to children is reused to
pass down the fd on unix. If we leave it alone, we'd have to duplicate the
mechanism on unix.


Regards, Dmitry

> ___
>
> Reply to this item at:
>
>   
>
> ___
>   Message sent via Savannah
>   https://savannah.gnu.org/
>
>

Re: [bug #60841] misleading statement in the manual

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

On Mon, Jun 28, 2021 at 10:23 AM Andreas Schwab  wrote:
> > "When make runs a recipe, variables defined in the makefile are placed into
> > the environment of each shell."
>
> Please also read the rest of the paragraph.

This statement should say "variables defined in the makefile can be
placed..." to match the reality and the rest of the paragraph.
In fact, the prior version used to say
"variables defined in the outer invocation can be passed to inner
invocations through the environment...".

regards, Dmitry

Re: [bug #60798] Make does not compile with GCC 11.1.0

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

On Sat, Jun 19, 2021 at 10:31 AM Dmitrii Pasechnik
 wrote:
> It's undefined behaviour in C to point to such a location, isn't it?
> Is this hack really needed?

There is no hack. It is pointer arithmetic in c. p[-1] is the same as *(p-1).
regards, Dmitry

Re: Keeping intermediate files

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

On Thu, May 20, 2021 at 4:29 PM Frank Heckenbach
 wrote:

>- just ".SECONDARY:" with no prerequisites which makes all
>  targets secondary (like I want), but also makes all targets
>  immediate, e.g. with this Makefile, if y exists and x doesn't,
>  it will remake x, but not y, which is not what I want:

You also do not want this, because this hurts performance badly.

> Am I missing a way to do it without adverse side-effects?

No. This is the state of affairs.

There is a proposed solution
.NOTINTERMEDIATE:

You can use it like this
.NOTINTERMEDIATE: %.h %.d hello.z
This will cause %.d %.h and hello.z files to not be treated as intermediate.

See https://savannah.gnu.org/bugs/?60297.
If you can build make yourself you can apply the patch attached to
this proposal.

regards, Dmitry

Re: Manual: Multiple outputs

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

On Mon, May 3, 2021 at 8:57 AM Paul Smith  wrote:
>   data.h: data.c ;
>
> (note the extra semicolon).  Now it will work.

Ofcourse, when data.c is present and data.h is missing, then make will
not recreate data.h. It'll run the empty rule.

Your original makefile
data.h data.c: data.foo
touch data.h data.c
data.h: data.c

is the same as

data.h: data.foo
touch data.h data.c

data.c: data.foo
touch data.h data.c

data.h: data.c

See what this makefile tells make to do.
This makefile tells make that when data.c is missing make needs to
touch data.h data.c. Sure this creates both files.
Same for data.h.
You'll need to either rewrite the makefile to use grouped targets as
Paul suggested, or use pattern rules, as you figured out.
i'd look if it was possible to rewrite like

all: data.h data.c
data.h: data.foo
touch $@
data.c: data.foo
touch $@
data.c: data.h

regards, Dmitry

Re: .SECONDARY: unwanted effect of not causing rebuilds when intermediate files missing

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

On Mon, Apr 5, 2021 at 7:28 PM Britton Kerin  wrote:
> Even if this behavior of .SECONDARY: is considered desirable

Whether or not it is desirable, it is there and there are makefiles
which use it and a change would break them.


>, it would
> be nice to have some way of telling make what I want to tell it, which
> is simply that I want all special handling of intermediate files
> disabled (i.e. no automatic removal or strangely weakened dependency
> handling).

We are discussing this very subject here https://savannah.gnu.org/bugs/?60297.

Also, always give .SECONDARY some prerequisites, otherwise performance suffers.
See https://savannah.gnu.org/bugs/?51454.

regards, Dmitry

Re: Intermediate file removal ... considered harmful??

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

On Wed, Mar 31, 2021 at 5:39 PM Paul Smith  wrote:

> Third, there's not a flexible way to disable intermediate files:
agree.

> I think it is still useful to keep intermediate files as a concept,
> where if an intermediate file in a chain of implicit rules doesn't
> exist but the mod time of the source end of the chain is newer than the
> target end of the chain, we don't bother to rebuild the chain.
agree.

> Leaving aside backward-compat issues, is there a current use-case for
> the auto-delete feature of intermediate files?
Perhaps only the same reason make was originally coded to remove
intermediate files, to free up space.
Space is limited on embedded devices. Building natively on embedded
devices may benefit from removal of intermediate files.
i personally have not found this removal to be useful.

i also have not found just removal alone to the root of the trouble.
But rather all these factors together
1. removal of intermediate files
and
2. absence of an intermediate file causes no rebuild
and
3. absence of a mechanism to mark chosen patterns as not intermediate.


regards, Dmitry

Re: gmake and ccache conspiring together in creating gremlins

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

On Tue, Feb 9, 2021 at 5:31 AM Edward Welbourne  wrote:

> Rather than removing the jobserver-auth data, you could amend the
> MAKEFLAGS to includ jobserver-auth data with plainly invalid fds,

i like jobserver-auth data with plainly invalid fds, because it lets
older binaries fail on parsing jobserver-auth
and print some (hopefully useful) error message.
E.g. make itself would print
"internal error: invalid --jobserver-auth string"


> e.g. -1, as the two fds

The program could read this -1 to (for example) uint16_t and interpret
as 65535 and fail to notice the parent is not giving any fd.
i'd rather provide no fd at all. E.g.
--jobserver-auth=

regards, Dmitry


>
> Eddy.
>

Re: gmake and ccache conspiring together in creating gremlins

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

On Mon, Feb 8, 2021 at 12:36 PM Edward Welbourne  wrote:
> Sounds to me like that's a bug: when the descriptors are closed, the
> part of MAKEFLAGS that claims they're make's jobserver file descriptors
> should be removed, since that's when the claim stops being true.

make uses posix_spawn by default to create children.
posix_spawn makes it difficult to modify env per child.
As a workaround the user can have the recipe remove (or modify) MAKEFLAGS
E.g.

%.o: %.c ; unset MAKEFLAGS && $(CC)  $(CFLAGS) -o $@ -c $<

regards, Dmitry

Re: gmake and ccache conspiring together in creating gremlins

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

On Mon, Feb 8, 2021 at 12:51 PM Dmitry Goncharov
 wrote:
>
> On Mon, Feb 8, 2021 at 12:36 PM Edward Welbourne  
> wrote:
> > Sounds to me like that's a bug: when the descriptors are closed, the
> > part of MAKEFLAGS that claims they're make's jobserver file descriptors
> > should be removed, since that's when the claim stops being true.
>
> make uses posix_spawn by default to create children.
> posix_spawn makes it difficult to modify env per child.
> As a workaround the user can have the recipe remove (or modify) MAKEFLAGS
> E.g.
>
> %.o: %.c ; unset MAKEFLAGS && $(CC)  $(CFLAGS) -o $@ -c $<

Oops. Forgot that posix_spawn takes an envp parameter.
Yes, worth fixing.

regards, Dmitry

Re: AW: Issue with VPN

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

> Question. Is there a change to optimize the function cp and rm?

In bash (in recipe lines) you can replace cp with
echo "$(dst

in make you can replace cp with
$(file >dst,$(file 

Re: [bug #59399] Expanding implicit macros in gmake (enhancement request)

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

On Sun, Nov 29, 2020 at 6:02 PM Jörg Schilling  wrote:
> I just verified that expanding $< and $* for explicit rules at all
> was an invention from SunPro Make. These macros have not been
> expanded by the classical UNIX make.


The seminal make manual of 1978 contains the following

"Before issuing any command, certain macros are set. $@ is set to the
name of the file to be ‘‘made’’. $? is
set to the string of names that were found to be younger than the
target. If the command was generated by
an implicit rule (see below), $< is the name of the related file that
caused the action, and $∗ is the prefix
shared by the current and the dependent file names."

See here
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.95.9198=rep1=pdf

regards, Dmitry

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

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

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

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

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

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

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

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";
 _directory_tree("$workpath/")
-or  ("Couldn't wipe out $workpath\n");
+or  ("Couldn't wipe out $workpath: $!\n");
   } else {
 mkdir ($workpath, 0777) or  ("Couldn't mkdir $workpath: $!\n");
   }
@@ -1129,8 +1129,9 @@ sub remove_directory_tree
   -e $targetdir or return 1;

   _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 _ && _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 

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, _logfile(0),
+  my $result = run_make_with_options($makefile, $options, _logfile(0),
 $err_code, $timeout, @call);
   _output($answer, _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 = _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) {
+_make_test(qq!
+$shell
+all:; \@$perl -e 'printf "$answer\\n"';
+ !, '', "$answer");
+}
+
+# test 15
+# Use perl as a shell.
+_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

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 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);
 }
   }
+  _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
 ";
 _output($answer,_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]

ed __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 labels, and
   g++ has since version 4.5.  Note to support C++ as well as C,
   _GL_UNUSED_LABEL should be used with a trailing ;  */
#if !defined __cplusplus || __GNUC__ > 4 \
|| (__GNUC__ == 4 && __GNUC_MINOR__ >= 5)
# define _GL_UNUSED_LABEL _GL_UNUSED
#else
# define _GL_UNUSED_LABEL
#endif

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

/* The __const__ attribute was added in gcc 2.95.  */
#if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95)
# defin

gmake-4.2.90 regression (segmentation fault in sum_up_to_nul )

[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(, (p), 4); \
+unsigned int val = 0; \
+size_t vsz = sizeof (val);\
+size_t pn = (plen);   \
+size_t n = pn < vsz ? pn : vsz;   \
+memcpy(, (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(, (p), 4);   \
+memcpy(, (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