[bug #18123] wildcard function fails (...)*/ expansion

Follow-up Comment #3, bug #18123 (project make): A fix for this was just made to the GLIBC repo (see bug referenced below). I'll pull the latest code into make's internal glob implementation for the next release, but for systems (like all GNU/Linux systems) that have glibc as their native library

[bug #18123] wildcard function fails (...)*/ expansion

Update of bug #18123 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #28134] inconsistent reporting of linux kernel builds with -j2

Update of bug #28134 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

Update of bug #33034 (project make): Status: Not A Bug => Fixed Assigned to:None => psmith Fixed Release:None => SCM _

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #4, bug #40241 (project make): Besides the fact that your patch would leak the strdup'ed string, it doesn't work: $ ./Release/make_msvc.net2003.exe -f test.mk --trace test.mk:2: target 'foo' does not exist echo foo foo /usr/bin/touch foo /usr/bin/sh: (/w foo: No such file or dir

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

URL: Summary: Interrupting a build with CTRL-C doesn't kill subprocesses Project: make Submitted by: glandium Submitted on: Mon 21 Oct 2013 12:28:18 AM GMT Severity: 3 - Normal

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #5, bug #40241 (project make): It worked for me, but of course I don't have your exact setup. I will have another look. (Don't worry about leaking memory, I just wanted to see if this kind of change fixes your problem. The actual change will have all this straightened up.) Th

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

Follow-up Comment #1, bug #40322 (project make): This doesn't happen for me. Does it happen for you always, or just with some Makefile's? Can you show an example of a Makefile and a session where Ctrl-C does not interrupt the Make run? There's special code in Make to handle the Ctrl-C situation

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

Follow-up Comment #2, bug #40322 (project make): The typical case where this happens is when link.exe is running to link xul.dll in a Firefox build. I'll check at some other random places. I'll also check what happens with the commands.c code in a debugger. ___

Re: [bug #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

Paul. Thank you very much! This means I'll be able to make professional use the many features and bugfixes which have arrived post-3.81 at some point. Given the flurry of other fit-and-finish fixes lately, would it be safe to assume there will be a 4.01 or equivalent upcoming in the foreseeable fu

make-4.0 allows empty ARFLAGS to be passed to ar

With GNU Make 4.0 on x86_64-unknown-linux-gnu I am unable to build qemu 1.6.{0,1} because it fails with AR libfdt/libfdt.a ar: two different operation options specified Makefile:234: recipe for target 'libfdt/libfdt.a' failed If I try to build it with make V=1 the output shows it has AR

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

Follow-up Comment #3, bug #40322 (project make): So it looks like from observing what happens, that subprocesses do get killed (although i haven't looked at what happens in a debugger), but they do so gently. Make doesn't wait for the process to actually be dead. Which has several interesting side

Re: [bug #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

On Sun, 2013-10-20 at 20:15 -0700, David Boyce wrote: > Paul. > > Thank you very much! This means I'll be able to make professional use > the many features and bugfixes which have arrived post-3.81 at some > point. Given the flurry of other fit-and-finish fixes lately, would it > be safe to assume

Re: make-4.0 allows empty ARFLAGS to be passed to ar

On Mon, 2013-10-21 at 04:05 +0100, Ken Moffat wrote: > With GNU Make 4.0 on x86_64-unknown-linux-gnu I am unable to build > qemu 1.6.{0,1} because it fails with > AR libfdt/libfdt.a > ar: two different operation options specified > Makefile:234: recipe for target 'libfdt/libfdt.a' failed