Re: Unable to build git@7774cfed62 using make@033330e

I'm afraid it's a bug in git's config.mak.uname. To point at one example, I think of many: https://github.com/git/git/blob/7774cfed62/config.mak.uname#L248 ... starts with a tab but, this human is reasonably confident, from eg the indentation, that it's intended as Make syntax rather than

Re: ---Please check it is a bug or not?

The script sets things up so that the cscope at the head of PATH will be a directory. I see the same behavior with the latest git version of Gnu Make running on glibc 2.31-13+deb11u8. Bash would report this as: mad@shuttle:~/tmp/zhao-2024-03-31/makebug$ PATH=bin:$PATH cscope bash: cscope:

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #7, bug #65537 (group make): [comment #6 comment #6:] That change on top of t'other Paul's from [comment #3 #3] and without my maintMakefile change from [comment #1 #1] is sufficient to stop the remaining warning, thanks. [comment #5 comment #5:] > GCC 4.2 and earlier doesn't

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #4, bug #65537 (group make): I made that change, then, not knowing how to activate it, just tried running bootstrap again. That failed the same way I saw, but didn't report, earlier today, somehow clobbering the gnulib that had been cloned before, causing a second run of

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #2, bug #65537 (group make): > Are you using the latest HEAD of the stable-202307 branch of gnulib? I'm using whatever Gnu Make cloned for me. > It should be SHA 2f47ff2e115712 I do indeed see that substring in: martind@stormy:~/download/make-2024-03-29/gnulib$ git log -n 1

[bug #65536] make.texi:5449: node `Using Variables' lacks menu item for `Conditionalizing' despite being its Up target

Follow-up Comment #2, bug #65536 (group make): I'm seemingly using: martind@stormy:~/download/make-2024-03-29$ makeinfo --version texi2any (GNU texinfo) 6.5 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Triage Status: None ___ Follow-up Comments: --- Date: Fri 29 Mar 2024 11:14:56 AM PDT By: Martin Dorey A fresh git clone of Gnu Make fails to build for me on Debian 10/Buster with:

[bug #65536] make.texi:5449: node `Using Variables' lacks menu item for `Conditionalizing' despite being its Up target

-Based Fixed Release: None Triage Status: None ___ Follow-up Comments: --- Date: Fri 29 Mar 2024 10:33:17 AM PDT By: Martin Dorey A fresh clone from git goes through boo

[bug #65533] gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower

Follow-up Comment #3, bug #65533 (group make): [comment #2 comment #2:] > the gmake process should consume close to 100% of CPU much of the time doing these variable expansions I like your thinking but that's that's not what Paul's theory predicts. Perhaps an example will help to explain why

[bug #65359] submake might will lose variable values if their names contain special char

Follow-up Comment #4, bug#65359 (group make): As demonstrated by eg: martind@stormy:~/tmp/make-65359$ cat Makefile export BADGER = wombat default:; echo BADGER = $$BADGER martind@stormy:~/tmp/make-65359$ Variables are communicated to subprocesses, be they Make, the shell or otherwise, via the

[bug #65359] submake might will lose variable values if their names contain special char

Follow-up Comment #1, bug#65359 (group make): Because then Make runs the command with a shell and, perhaps particularly after Shellshock, shells are increasingly diligent about cleaning the environment (eg

Re: Behavior change related to MAKEFLAGS and recursive make in version 4.4.1

I can reproduce the behavior with today's git code (modulo the one unpushed change of Dmitry's that has my +1, https://savannah.gnu.org/bugs/index.php?64259). Rereading https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html, I think you've got a case. My two cents is

Re: New conditional assignment facility

* Why is that? I imagine because that's how, to my surprise, it is today: martind@stormy:~/tmp/make-conditional-assignment-2024-01-22$ cat Makefile A := 42 A += $(shell hello) martind@stormy:~/tmp/make-conditional-assignment-2024-01-22$ make make: hello: No such file or directory make: ***

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

rom. From: bug-make-bounces+martin.dorey=hds@gnu.org on behalf of Haoxin Tu Sent: Saturday, January 20, 2024 20:03 To: Martin Dorey Cc: psm...@gnu.org ; bug-make@gnu.org Subject: Re: [bug #64551] Possible null pointer dereference on the function get_buf

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

xin Tu ; Martin Dorey Cc: bug-make@gnu.org Subject: Re: [bug #64551] Possible null pointer dereference on the function get_buffer * EXTERNAL EMAIL * On Sat, 2024-01-20 at 23:37 +0800, Haoxin Tu wrote: > But I don't understand why the second invocation of `xrealloc` can > not re

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

* once the second invocation of `xrealloc` ... returns zero But it doesn't, it just recurses, calls get_buffer again, again likely fails and recurses still further until the stack is blown. Or it did until

Re: [bug #64571] Add option to print targets

* even on relatively ancient distro I could easily install it on Debian Wheezy (via wheezy-backports), a release from ten years ago. I can't see someone using the next version of Gnu Make and wanting cutting edge facilities for debugging their makefiles on such a crusty old thing. JSON

[bug #64259] Regression in master: make ignores statements it should not ignore.

Follow-up Comment #3, bug#64259 (group make): Paul did pretty much explicitly say in the introducer, bug #64185, that he wasn't interested in being told about: > people indenting their conditionals with the recipe prefix ... and yet here I am, sorry, pointing at the tab still at

[bug #64259] Regression in master: make ignores statements it should not ignore.

Follow-up Comment #2, bug#64259 (group make): The change suggested here doesn't treat these two cases quite symmetrically: martind@stormy:~/tmp/make-missing-endif$ printf 'ifeq "a" "a"\n\tendif\ndefault:;\n' > Makefile; ~/download/make/make Makefile:2: *** recipe commences before first target.

[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

Follow-up Comment #9, bug#63650 (group make): Interesting idea, one that doesn't seem to be ruled out by anything in the original problem report, bug #10593. (I have a copy of the Makefile from that bug with an mtime one day earlier than the submission date. It looks like my idiolect. Guess I

Re: Problem setting a variable inside a target

Because the ifeq was evaluated during the first phase but the eval was deferred to the second. https://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html From: Ed L Wolf Sent: Monday, September 25, 2023 03:32 To: Martin Dorey ; bug-make@gnu.org

Re: Problem setting a variable inside a target

> The eval statement below highlighted in red is not working Perhaps you'd expect to see "BADGER is wombat" from: mad@shuttle:~/tmp/wolf-2023-09-24$ cat Makefile default:   $(eval BADGER = wombat) ifeq ($(BADGER),wombat)   echo BADGER is wombat else   echo BADGER is not wombat endif

Re: building failure

An internet search for "No rule to make target debian/-certs.pem needed by certs/x509_certificate_list" reveals lots of people with similar trouble, with many suggestions for how to avoid the issue, eg in:

Re: [PATCH 1/6] Fix GCC compile warning for "declaration-after-statement"

Primed by our earlier discussion, I wondered "How does that fix the bad-function-cast warning?", before belatedly noticing the Subject. From: bug-make-bounces+martin.dorey=hds@gnu.org on behalf of Torbjörn SVENSSON Sent: Friday, June 9, 2023 07:39 To:

Re: Unable to cross build for Windows

> in some MinGW64 header files? Easily eliminated: martind@sirius:~/tmp/svensson-2023-06-08$ cat make.c #include intptr_t _get_osfhandle(int); typedef void* HANDLE; HANDLE fn() {   return (HANDLE)_get_osfhandle(0); } martind@sirius:~/tmp/svensson-2023-06-08$ gcc -c -Wbad-function-cast make.c

[bug #64129] Using $(filter ...) on a variable with a large number of words causes seg fault

Follow-up Comment #2, bug #64129 (project make): Problem reproduced in 4.3, as claimed in OP. Problem not reproduced in 3.81, 4.1, 4.2.1, 4.3.90, 4.3.91, 4.3.92, 4.4.0.90, 4.4.0.91, 4.4.90 (today's code). Stack trace: In 4.3: (gdb) bt #0 0x5556828d in func_filter_filterout

Re: Warnings on '$\\'

> Without the '$\\' syntax, I get everything on one line I didn't understand that until I'd tried it. With just \ as line ending, the G_TRACE macro definition ends up on one line. With \\ as line ending, it ends up with \\ as line ending. With $\\ as line ending, it ends up with \, line

Re: No progress output when make 4.4.1 builds Linux 4.19 and earlier

> it's been bugging me locally for a bit I posted a quiet= work around on the make command line, for those of us who wouldn't easily be able to apply any change to the kernel side, a couple of weeks ago to: https://savannah.gnu.org/bugs/?63818 V=1 stopped working for Linux kernel module builds

Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'

Is it possible that suspiciously half null pointer came from: https://git.savannah.gnu.org/cgit/make.git/tree/src/read.c#n3480 nlist = (const char **)gl.gl_pathv; ... and it's sliced off half the gl_pathv pointer through calling an implementation of glob that wasn't compatible

Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'

What a great looking bug report. Tiny reproducer, clear range of things tried, clear crash with an effort to debug it. But there's a problem. The stack trace includes: frame #7: 0x000196b1 make`variable_expand_string(line="", string="$(wildcard

[bug #63818] V=1 stopped working for Linux kernel module builds with make-4.4

: None Triage Status: None ___ Follow-up Comments: --- Date: Sun 19 Feb 2023 11:59:36 AM PST By: Martin Dorey As reported by Jan Palus in https://lists.gnu.org/archive/html/bug-mak

[bug #63157] Unlink temporary files.

Follow-up Comment #26, bug #63157 (project make): Ach, it did reproduce for me, with or without Dmitry's modification. I was just looking in the wrong place, despite Frank providing copy-and-paste instructions on where to look. Perhaps I'd just read about MAKE_TMPDIR and assumed that they'd end

[bug #63157] Unlink temporary files.

Follow-up Comment #23, bug #63157 (project make): Frank wrote [ I now found a way to reproduce it quite easily on my system. As I suspected, it seems to be SIGPIPE: % rm -f /tmp/G* % cat Makefile all: ; sleep 1 % make -j2 -O 2>&1 | : % ls -l /tmp/G* prw--- 1 frank frank 0 19. Okt 22:42

Re: GNU make 4.3.91 on Debian 9.1

put-sync.mk.15:3: all] Terminated I haven't seen that one, though it bears quite a resemblance to the temp_stdin symptom. From: Martin Dorey Sent: Tuesday, October 18, 2022 22:05 To: Bruno Haible ; bug-make@gnu.org ; psm...@gnu.org Subject: Re: GNU make 4.3.91 on Deb

[bug #52018] suggestion: test case for glob with dangling symlink

Follow-up Comment #6, bug #52018 (project make): If I've understood this correctly, then the upshot of the new test, https://git.savannah.gnu.org/cgit/make.git/commit/?id=f9ba22e02924e0a869a6e40ef4a70ee884d1ec46, is that we should expect a "failure", which is really just documenting legacy

Re: GNU make 4.3.91 on Debian 9.1

>> On Debian 9.1.0 / x86 (a machine with glibc 2.24) ... >> 3 tests fail For me on Debian 9.13 amd64 (a machine with glibc 2.24) it remains just the one failure, the one I alluded to in https://savannah.gnu.org/bugs/?63016, so it's not very new. Indeed, output below suggests it's several years

Re: .SECONDARY unexpectedly affects rule invocation

> A further note: it's version 4.3 of make Behavior seems the same to me from (at least) 3.81 to 4.3.91 (inclusive). Isn't this slightly simplified example sufficient to demonstrate the same behavior... martind@sirius:~/tmp/Pomaznoy-2022-10-04$ cat Makefile RECIPE = echo "Making $@ from $^" >

Re: GNU make 4.3.90 release candidate available

> It's more probable that David has outdated certificate DB and/or > outdated GnuTLS on his machine. Thanks once again to Microsoft for obeying Dorey's Law of Marketing with "safelinks", I only belatedly see David's evidence included "--2022-09-26 09:12:58--" which rather says that his clock

Re: GNU make 4.3.90 release candidate available

It doesn't look invalid to me: martind@sirius:~$ < /dev/null openssl s_client -connect alpha.gnu.org:https | openssl x509 -noout -text | grep Not depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1

Re: 4.3.90 release candidate segfaults on linux and solaris

copying the environment somewhere else. Huh, even just the environ pointer. From: Bug-make on behalf of Martin Dorey Sent: Sunday, September 25, 2022 07:09 To: psm...@gnu.org ; Denis Excoffier Cc: bug-make@gnu.org Subject: Re: 4.3.90 release candidate

Re: 4.3.90 release candidate segfaults on linux and solaris

be surprised if that doesn't crash for Paul too because I suggest that the kernel version isn't actually important either. From: Paul Smith Sent: Sunday, September 25, 2022 06:23 To: Martin Dorey ; Denis Excoffier Cc: bug-make@gnu.org Subject: Re: 4.3.90

Re: 4.3.90 release candidate segfaults on linux and solaris

I have a 32 bit Debian Squeeze (so 2011 era, with gcc-4.4 - too early for asan - and libc 2.11, so two Debian releases earlier than Denis’s) chroot lying around. Unsurprisingly, his reproducer crashes for me too, configured with no options and make run with no arguments. gdb’s reporting line

[bug #63070] posix_spawn fails to run a child process.

Follow-up Comment #12, bug #63070 (project make): Ah, so the cause was as noted in https://savannah.gnu.org/bugs/?57022#comment5: > I leaked a copy of the filename because I'm really a C++ programmer, whose string literals are const. Thanks for sorting it out, Dmitry, and sorry for the

[bug #63070] posix_spawn fails to run a child process.

Follow-up Comment #4, bug #63070 (project make): > it's not feasible to test the runtime behavior of posix_spawn() in configure Despite it being "problematic", isn't that how we solved the not entirely dissimilar bug #57022 (Error 127 executing a script with no #!) in

Re: [bug #63016]

> Compiling the Linux kernel with git make HEAD: > > *** Recursive variable 'KERNELRELEASE' references itself (eventually).  Stop. Huh, I saw that too when compiling kernel modules under the control of the same proprietary make files as provoked my original report. I was really not looking

Re: New release of GNU make

> I think there's a better way to handle this than the one you suggest Let's not blame Sam for my patch, with its gruesome returning, and hence presumably exporting, of some strdup()d boilerplate to stop the caller from crashing. > why does this prevent doing any more testing? I expect he

Re: New release of GNU make

> I just use `git clean -fdx` Force, recurse into untracked directories and ignore gitignore so that build products are deleted. Just the ticket, thanks. README.git mentions "clean" and "distclean" but not this handy trick.

[bug #63016] Recursive variable references itself (eventually) when exporting to $(shell)

: None Triage Status: None ___ Follow-up Comments: --- Date: Sun 04 Sep 2022 04:28:29 PM PDT By: Martin Dorey With this Makefile: martind@sirius:~/tmp/make-2022-09-04$ cat Ma

Re: New release of GNU make

https://git.savannah.gnu.org/cgit/make.git/commit/configure.ac?id=0793658c09a8f33581dae6dfbe2483ea279e72b1 ... imposed a dependency on autoconf 2.71. Such is the way of the world, but I suggest that's worth a mention in README.git, like the dependency on automake 1.16.1 already gets, because

Re: 回复： 回复： Implicit rule for linking multiple object files

Sent: Thursday, August 11, 2022 11:37 To: Martin Dorey ; Philip Guenther Cc: psmith ; bug-make Subject: 回复： 回复： Implicit rule for linking multiple object files * EXTERNAL EMAIL * Thanks Martin, Your Makefile is too advanced for me to understand by now. I tested out the below fiv

Re: 回复： Implicit rule for linking multiple object files

> I want to compile objects in order of the writting Just because, today, make happens to pick nearly what you want it to do without being told about your ordering constraint, doesn't mean that you should rely on it continuing to do so. You should teach make about that order. You could

[bug #62840] make --version in pipe return SIGPIPE

Follow-up Comment #2, bug #62840 (project make): Just for completeness or academic interest, then, this makes it happen reliably for me: set -o pipefail; { ruby -we '$stdout.write("x" * 4096)'; make --version; } | head -n1; echo $? That behaved the same all the way back to make-3.81. This

[bug #62595] Add ability to read .env files into make and

Follow-up Comment #5, bug #62595 (project make): I'd never heard of these env file things, so appreciated the well-written posts that those links point to. Why would this feature be better in Make rather than in a wrapper? If you wanted, for some reason that I'm struggling to guess, to keep

Re: Make Docs Errata

> It says SECONDARY EXPANSION, while the first time the manual is referring to > the first one I think it means what it says. I'd try to suggest a rewording for clarity... but I'm not seeing how it could be clearer. Perhaps you could suggest one? From:

Re: Potential Bug: `.PHONY` targets and order-only prerequisites

> all your targets are .PHONY, and thus are always rebuilt anyway If you "make down", the rule for "down-clean" doesn't run. They're only rebuilt if something causes them to be considered. > order-only prerequisites are totally irrelevant and have no impact on > your makefile. If you

Re: bug or feature make -j4 option? but successfully applied all changes!

> bug or feature make -j4 option? but successfully applied all changes! This: /var/lib/dkms/rtl8821ce/5.5.2.1/build/os_dep/osdep_service.c: In function ‘thread_exit’: /var/lib/dkms/rtl8821ce/5.5.2.1/build/os_dep/osdep_service.c:1297:2: error: implicit declaration of function

[bug #62397] jobserver unavailable from $(shell $(MAKE)...)

Follow-up Comment #2, bug #62397 (project make): I don't think so: martind@sirius:~/tmp/D150109$ cat 2.make makeprog := $(MAKE) OUTPUT := $(shell env | grep MAKEFLAGS 1>&2; $(makeprog) -f 3.make) default:; @true martind@sirius:~/tmp/D150109$ ~/download/make/make -j2

[bug #62397] jobserver unavailable from $(shell $(MAKE)...)

URL: Summary: jobserver unavailable from $(shell $(MAKE)...) Project: make Submitted by: mdorey Submitted on: Mon 02 May 2022 05:42:45 PM PDT Severity: 3 - Normal Item

[bug #62200] Make tries to execute directories name as commands instead of using shell PATH resulting failure with permission denied

Follow-up Comment #5, bug #62200 (project make): > typed the recipe command line into your shell prompt I see the point but I'm not sure I'd put it *quite* that way. Didn't bash win the Shell Wars? martind@sirius:~/tmp/make-62200$ PATH=$(pwd):$PATH /bin/sh -c asdf /bin/sh: 1: asdf: Permission

[bug #62200] Make tries to execute directories name as commands instead of using shell PATH resulting failure with permission denied

Follow-up Comment #1, bug #62200 (project make): Oh no, not error 127 again. The error message here is the strerror form of EACCES, which currently seems to come (on my build on reasonably modern Linux, with findprog-in and posix_spawn) from this change:

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

=\fIfile\fR Do not remake the file From: David A. Wheeler Sent: Friday, March 18, 2022 09:08 To: Ambrus Sumegi Cc: psm...@gnu.org ; Martin Dorey ; bug-make@gnu.org Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

> the statement after the pipe also gets executed Would you have Make parse the shell command, assuming that SHELL isn't eg /usr/bin/perl, splitting off anything after | and maybe ; and && and, why not, ||, so it only dry-runs the part of the command that invoked $(MAKE)? The current behavior

Re: Bug in $(shell ...) I can't understand

>> because this redirects the output of the bad-program, but it's the >> shell printing the error not the program. Dmitry's reply is more constructive but those strace arguments, all the pids and pipe inodes, ow my head, so perhaps it's worth a simple demonstration that, despite the undisputed

Re: [BUG] --warn-undefined-variable is not triggered in prerequisites

That already seems to have been fixed: martind@sirius:~/tmp/make-undefined-variables-2022-01-27$ cat Makefile MAKEFLAGS += --warn-undefined-variables a: $(foo); touch $@ martind@sirius:~/tmp/make-undefined-variables-2022-01-27$ ~/download/make/make --version GNU Make 4.3.90 Built for

Re: Bug report of Oyster River Protocol made by macmanes lab.

> I found a bug If you have, then it's more likely in the documentation for this "Oyster River Project" than in the code of the Oyster River Project itself, let alone Gnu Make. > /bin/bash: activate: No such file or directory That looks like the kind of problem you get when one of Python's

Re: make -j does not work on RedHat7.7 VM

> Could you help to look into it? Not much, sorry. > Is this a misconfiguration in my project build environment or a bug in GNU > Make 4.2.1? Maybe you'd be convinced that it's the former if you run a test like this: martind@sirius:~/tmp/mason-zhu-2021-12-21$ cat Makefile TARGETS = a b c

Re: [PATCH] doc: note that $(wildcard) is implemented in terms of glob(3)

It was documented but only in NEWS: martind@sirius:~/download/make$ sgrep wildcard | grep sort ./NEWS:179:* All wildcard expansion within GNU make, including $(wildcard ...), will sort ./NEWS:426: results from wildcard expansions, use the $(sort ...) function to request ./ChangeLog.3:1586: *

Re: Make language

> I installed make 3.81 for Windows I wonder where you got a Windows binary distribution of a 15 year old version of Make. This mailing list is from the GNU project, whose download site is linked from https://www.gnu.org/software/make/ as http://ftp.gnu.org/gnu/make/. I see only source

Re: sub makefile does not use correct value of CFLAGS from top make file,

# Also note the top make file removes the default rule for %.o:%.[Sc], but # the default rules are still being used. I fear you think that .EXPORT_ALL_VARIABLES should have exported your custom rule to the sub-make. It won't. I didn't notice any difference in say 4.1 but I dug out a

[bug #60557] Built-in rule for preprocessing assembler programs doesn't work as documented

Follow-up Comment #1, bug #60557 (project make): I thought I'd found where PREPROCESS.S was added, in 2014, under: https://git.savannah.gnu.org/cgit/make.git/commit/?id=c0380823a27f14cdc8274ad03c0dcab216d1380b ... but I must be getting confused by the limited diff context because it's there all

Re: [bug #60538] Environment variable overrides explicit assignment

ps it doesn't need to be, but isn't expanded before being exported. From: David Boyce Sent: Thursday, May 6, 2021 09:48 To: Paul D. Smith Cc: Shareef Jalloq ; Martin Dorey ; Boris Kolpackov ; bug-make Subject: Re: [bug #60538] Environment variable overr

[bug #60538] Environment variable overrides explicit assignment

Follow-up Comment #4, bug #60538 (project make): Looks like it's working as designed to me. If I do: $ make -n -p -- TESTNAME=test_mtp_remap ... like in your original post: > make blah TESTNAME=mytest1 ... then I see that: MAKEFLAGS = np -- $(MAKEOVERRIDES) ... where: MAKEOVERRIDES =

Re: GNU Make documentation example error

Looks like the report in: https://lists.gnu.org/archive/html/bug-make/2021-01/msg00016.html ... only this time without any version number. The answer a couple of weeks ago was: https://lists.gnu.org/archive/html/bug-make/2021-01/msg00017.html (I couldn't find it with Google, even though I

Re: notes about make docs p 3.5

> It'l be very good to have some examples with explanations in the docs. Maybe so. Concrete suggestions are easy to discuss, like: > 1) make starts with a clean slate-> make starts with a clean sTate The "clean slate" idiom seems more natural to this native English speaker. Would "starts

[bug #59243] Overcomplicated example of automatic dependency configuration

Follow-up Comment #1, bug #59243 (project make): Given set -o pipefail isn't on by default even where supported, the OP neglects the benefit of set -e in preventing the existing dependency file from being truncated to empty if something goes wrong with the compiler step. Even the original

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #12, bug #59154 (project make): [comment #10 comment #10:] > If the variable is passed to a single shell then it will print an error at the second "cd". Eh? martind@sirius:~/tmp/make-59154$ bash -c 'cd foo && echo one cd foo && echo two' one two

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #1, bug #59154 (project make): I thought this might be related to https://en.wikipedia.org/wiki/Shellshock_(software_bug) but make is exec()ing the wrong command: martind@sirius:~/tmp/make-59154$ export PUB="$(echo hello; echo world)" martind@sirius:~/tmp/make-59154$ cat

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

Looks a likely match for: http://mail.openjdk.java.net/pipermail/build-dev/2014-November/013597.html Fixed in jdk8u in 2014. Surely our OP is using that already... but he does say jdk8 rather than jdk8u, so maybe not. From: Bug-make on behalf of Paul Smith

Re: Maybe a bug in make manual. https://www.gnu.org/software/make/manual/make.html#Overriding-Makefiles

I think the text is as intended. The previous paragraph talks about the -t, -n and -q switches as being treated similarly. The example could use any but has to pick one. From: Bug-make on behalf of 牛啊 <285430...@qq.com> Sent: Sunday, May 24, 2020 07:26 To:

[bug #58420] PATH changes are not applied in $(shell) function

Follow-up Comment #2, bug #58420 (project make): $(shell) commands in a recipe... well, we've all seen it done. But, hang on, PATH doesn't behave specially for me: martind@sirius:~/tmp/make-58420$ cat Makefile NOT_PATH := /nonexistent:$(NOT_PATH) $(shell echo during parsing

[bug #58364] Inconsistent behavior between 4.3 and 4.2.1

Follow-up Comment #4, bug #58364 (project make): Perhaps it wasn't apparent to albert that it's in the NEWS file now, ready for the next release, as of: http://git.savannah.gnu.org/cgit/make.git/commit/NEWS?id=660a2eafe52b8fad0dbee8ccddb990015dc68b54 Editing the NEWS file in the previous

[bug #57914] abspath does resolve symlink

Follow-up Comment #5, bug #57914 (project make): I haven't seen half the mails relating to this bug, which might explain how it lay unloved for so long. I don't think I'm really adding anything to Boyski's posts, which I hadn't seen (and they aren't in my "spam folder"), but here's a

Re: Error In Installing FreeBayes

> adjust the build scripts to comply with your older version https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827132 (debhelper: make-4.2 renamed --jobserver-fds to --jobserver-auth causing parallel build issues) shows it’s not impossible that third party build scripts might hard code such

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

Follow-up Comment #6, bug #57676 (project make): > I would consider this a bug in make Well, it's not wrong that there is no rule to make the dependency file and adding one does silence it (this is make-4.3.90): martind@paris:~/tmp/make-57676$ cat Makefile2 -include deps BADGER := $(shell touch

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

Follow-up Comment #4, bug #57676 (project make): If it is that, then the behavior change was introduced by git commit c5ccc4930c3805604813def4455bc2e90635349e: [SV 40236] Handle included file open failures properly. ___ Reply to this

[bug #40657] Suffix rules and prerequisites

Follow-up Comment #5, bug #40657 (project make): This was revisited in http://git.savannah.gnu.org/cgit/make.git/commit/?id=3b5e47b2e2904884a9d853848be3348b7cdd4f8a largely thanks to a report from Dennis Clarke about building FreeBSD packages at the end of

Re: GNU make 4.2.93 release candidate available

> accept prerequisites and implement them as the user expects, which violates POSIX ... and which never happened before I fear implementing what the makefile author asked for instead of what they got... could expose other latent issues in their makefile. > Martin had suggested some kind of

Re: ENOEXEC from exec*() functions...?

nks to some new for loop initial declarations in file.c and rule.c, which weren't legal in -std=gnu90, the compiler's default dialect. From: Paul Smith Sent: Friday, January 3, 2020 09:16 To: Martin Dorey ; Eli Zaretskii Cc: bug-make@gnu.org Subject: Re: ENOEXEC f

Re: orange pi 4B Report bugs

>From the attachment: Platform RK3399 is build OK, with new .config(make rk3399_defconfig) Complete U-boot compile Start compiling the kernel ... make: the '-j' option requires a positive integer argument Usage: make [options] [target] ... I think that's a bug at:

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

Follow-up Comment #5, bug #57022 (project make): Argh, all those hours fighting autoconf to now see Dmitry had already sent a similar patch. I see Paul didn't like the cross-compilation issue. That was when it just looked like an ENOENT problem, which he could sensibly solve at runtime, before

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

Follow-up Comment #3, bug #57022 (project make): > SHELL = /bin/bash ... > the bug does not show up). Good spot, thanks Denis. I see the same. I see a "goto slow" code path in the source when the shell isn't /bin/sh. I don't suppose you had a chance to try my attached configure.ac patch?

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

URL: Summary: Error 127 executing a script with no #! Project: make Submitted by: mdorey Submitted on: Tue 08 Oct 2019 05:29:37 PM PDT Severity: 3 - Normal Item Group:

Re: ENOEXEC from exec*() functions...?

/make-2019-10-08$ dpkg --status libc6:amd64 ... Version: 2.24-11+deb9u4 From: Martin Dorey Sent: Tuesday, October 8, 2019 12:00 To: Eli Zaretskii ; psm...@gnu.org Cc: bug-make@gnu.org Subject: Re: ENOEXEC from exec*() functions...? Sorry to reanimate this but I

Re: ENOEXEC from exec*() functions...?

Sorry to reanimate this but I think I've run into a regression in 4.2.92 over 4.2.1 that's probably related to this old email thread. Bug or email, bug or email... email: martind@swiftboat:~/playpen/make-2019-10-08$ cat > Makefile all: ; ./dodgy martind@swiftboat:~/playpen/make-2019-10-08$ cat

[bug #40657] Suffix rules and prerequisites

Follow-up Comment #4, bug #40657 (project make): > POSIX standard is very clear Works for me, thanks. ___ Reply to this item at: ___ Message sent via

[bug #40657] Suffix rules and prerequisites

Follow-up Comment #2, bug #40657 (project make): This is now in the NEWS file as: * WARNING: Backward-incompatibility! Contrary to the documentation, suffix rules with prerequisites were being treated BOTH as simple targets AND as pattern rules. Behavior now matches the documentation, and

Re: Immediate and deferred expansion documentation rewording

aluated. exp needn't itself appear again. From: Maris Razvan Sent: Tuesday, October 1, 2019 13:19 To: Martin Dorey Cc: bug-make@gnu.org Subject: Re: Immediate and deferred expansion documentation rewording * EXTERNAL EMAIL * Thank you for your answer.

Re: Immediate and deferred expansion documentation rewording

> I understand the following Apart from the word "cmake", that chimed with my understanding. > a completely different meaning than the one used in the previous sentences I think the meanings are consistent if "a section of a construct" is itself a "construct". > however one situations >

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #20, bug #49014 (project make): Surely Kurt was running with that? Mind, he didn't say. I haven't seen my Linux problem in the 2+ years since applying b552b0525198. ___ Reply to this item at:

[bug #56764] Different behavior of printf command executed from Makefile and from shell.

Follow-up Comment #3, bug #56764 (project make): [comment #2 comment #2:] > When make invokes printf it's assuming a POSIX shell, and running the /usr/bin/printf executable not the bash builtin. Look ma, no /usr/bin/printf: mad@shuttle:~/tmp/make-56764$ strace -f make 2>&1 | grep exec

  1   2   3   >