gmake-4.2.90 regression (segmentation fault in sum_up_to_nul )

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

Re: gmake-4.2.90 regression (error message missing)

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

Re: gmake-4.2.90 patch

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

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

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

gmake-4.2.90 regression (error message missing)

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

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

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

gmake-4.2.90 patch

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

Re: vpathplus test 2 patch

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

vpathplus test 2 patch

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

patch to fix grouped_targets test 1

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

patch realpath on aix

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

patch locale settings

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

Re: patch locale settings

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

Re: patch locale settings

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

Re: patch out of source builds

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

Re: patch locale settings

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

Re: patch locale settings

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

patch to fix features/archives test 10 on sunos

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

patch out of source builds

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

Re: patch, test suite fails to run valgrind

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

patch, test suite fails to run valgrind

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

patch, new test features/exec.

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

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

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

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

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

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

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

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

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

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

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

Re: Phony targets not being made

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

Re: Phony targets not being made

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

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

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

make-4.2.93 patch port to c90

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

make-4.2.93 patch enhance error reporting from the test suite

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

Re: patch, new test features/exec.

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

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

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

Re: make-4.3: wildcard test #9 fails

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

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

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

Re: embedded newlines in shell function variable expansion

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 >

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

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

Re: export vs $(origin )

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

Re: export vs $(origin )

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

Re: simple assignment of target-specific variables

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

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

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

Re: simple assignment of target-specific variables

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

Re: simple assignment of target-specific variables

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

Re: simple assignment of target-specific variables

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

Re: AW: Issue with VPN

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

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

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

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

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,

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

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

Re: Manual: Multiple outputs

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

Re: gmake and ccache conspiring together in creating gremlins

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

Re: gmake and ccache conspiring together in creating gremlins

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

Re: gmake and ccache conspiring together in creating gremlins

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

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

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

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

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

Re: Make language

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

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

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: [bug #61226] A regression prevents generation of missing included dependency files.

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

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

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

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

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.

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

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

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

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

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

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

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

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.

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

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,

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

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

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

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

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

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

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

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