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

2013-10-20 Thread Paul D. Smith 
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 GNU make will defer to the system glob implementation, so
you'll need to update your system glibc to get this fix.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

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

2013-10-20 Thread Paul D. Smith 
Update of bug #18123 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

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

2013-10-20 Thread Paul D. Smith 
Update of bug #28134 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => 4.0

___

Follow-up Comment #4:

In 4.0 we set stdout and stderr to append mode (for systems where this is
supported).  So you should not see this problem anymore.  Also in 4.0 there is
the output-sync feature you can use if you want (but this is not necessary to
avoid losing output).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

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

2013-10-20 Thread Paul D. Smith 
Update of bug #33034 (project make):

  Status:   Not A Bug => Fixed  
 Assigned to:None => psmith 
   Fixed Release:None => SCM

___

Follow-up Comment #21:

I have pushed a change to the Git repository.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

[bug #40241] CreateProcess failure with unixy paths

2013-10-20 Thread Mike Hommey 
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 directory
test.mk:2: recipe for target 'foo' failed
make_msvc.net2003: *** [foo] Error 127

(test.mk is the same as in comment #2, but with an additional "echo foo" in
the recipe)

Note without the "echo foo", the error message is borked:
$ ./Release/make_msvc.net2003.exe -f test.mk --trace
test.mk:2: target 'foo' does not exist
/usr/bin/touch foo
/usr/bin/sh: Ó<.wÿ: No such file or directory
test.mk:2: recipe for target 'foo' failed
make_msvc.net2003: *** [foo] Error 127

Which suggests unintialized memory use or something alike.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

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

2013-10-20 Thread Mike Hommey 
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
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.0
Operating System: MS Windows
   Fixed Release: None
   Triage Status: None

___

Details:

When interrupting a build with CTRL-C on a win32 build, whatever was run by
make at the time keeps running. This prevents subsequent make runs to run
properly, either because of file locking or because the still running commands
may alter the build directory during the second build.

Note this is not a problem new to 4.0, it happened with previous releases too,
as I am told.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

[bug #40241] CreateProcess failure with unixy paths

2013-10-20 Thread Eli Zaretskii 
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.)

Thanks for the feedback.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

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

2013-10-20 Thread Eli Zaretskii 
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 (look for
SuspendThread in commands.c).  Perhaps it somehow doesn't do its job in your
case?


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

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

2013-10-20 Thread Mike Hommey 
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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

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

2013-10-20 Thread David Boyce 
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 future?

David

On Sun, Oct 20, 2013 at 10:09 AM, Paul D. Smith  wrote:
> Update of bug #33034 (project make):
>
>   Status:   Not A Bug => Fixed
>  Assigned to:None => psmith
>Fixed Release:None => SCM
>
> ___
>
> Follow-up Comment #21:
>
> I have pushed a change to the Git repository.
>
> ___
>
> Reply to this item at:
>
>   
>
> ___
>   Message sent via/by Savannah
>   http://savannah.gnu.org/
>

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

make-4.0 allows empty ARFLAGS to be passed to ar

2013-10-20 Thread Ken Moffat 
 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
ARFLAGS=""

 It builds if I export ARFLAGS="rv".  If I have understood
the reply on the qemu-devel list correctly, qemu deliberately passes
empty ARFLAGS and relies on the following in 'info make' :
`ARFLAGS'
 Flags to give the archive-maintaining program; default `rv'.


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

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

2013-10-20 Thread Mike Hommey 
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 effects:
- the process keeps running for a little while, and eventually dies
- it stays alive longer than it takes for make to (try to) remove the target
file (xul.dll in my case). This has different possible outcomes, one of which
is make failing to remove the file with a permissions denied error, the other
of which is make supposedly removing the file, but the file being there after
link.exe is done.

Seeing the code, it seems to me this could happen on unix as well with a
process that has a long "shutdown" when receiving SIGTERM/SIGINT.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

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

2013-10-20 Thread Paul Smith 
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 there will be a 4.01 or equivalent upcoming in the
> foreseeable future?

Yes, before too long.  I don't plan on any major features in the next
release, just cleanup and bug fixing.

I don't plan on a release right away (like this month) though.


I have to admit I still just don't understand the problem here.  Surely
no one is building kernels that old (pre-2.6.34) without any patches at
all applied; that sounds inconceivably insecure.  Why not just add one
more patch that changes the 3 places (at most) in the makefiles that
have this problem to the suite of patches that are already applied to
those old kernels when you build them?  It seems insane to me to avoid
updating tools merely because of a few lines of makefile change in
kernels that are almost 4 years old.

Anyway.  It will work for now, apparently.


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

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

2013-10-20 Thread Paul Smith 
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
> 
>  If I try to build it with make V=1 the output shows it has
> ARFLAGS=""
> 
>  It builds if I export ARFLAGS="rv".  If I have understood
> the reply on the qemu-devel list correctly, qemu deliberately passes
> empty ARFLAGS and relies on the following in 'info make' :
> `ARFLAGS'
>  Flags to give the archive-maintaining program; default `rv'.

There must be something else going on in your makefile.  The built-in
value for ARFLAGS is still present; you can see it set:

  $ make -p -f /dev/null | grep ARFLAGS
  make: *** No targets.  Stop.
  ARFLAGS = rv
  $(AR) $(ARFLAGS) $@ $<

Something in your makefile is overriding this value.

Perhaps you are setting MAKEFLAGS to add the -R flag (which disables
built-in variables)?  Or, you're overriding it somehow.

If you run:

  $ make -p -n

and search the output for ARFLAGS, the comment before should tell you
where that variable is being assigned.


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