Follow-up Comment #4, bug #40322 (project make):
That is not what is supposed to happen.
When you press Ctrl-C, the SIGINT handler is invoked, this is the function
fatal_error_signal defined on command.c. (Please verify that the signal
handler is indeed invoked.) Since on Windows SIGINT
Update of bug #26075 (project make):
Status:None = Works for me
Open/Closed:Open = Closed
Fixed Release:None = 4.0
On Mon, Oct 21, 2013 at 12:02:20AM -0400, Paul Smith wrote:
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
It's the long one (subdir-dtc) where the problem exists.
Obvious first step: configure quiet-command to actually show the
command, or remove this wrapping from the command, so that you can see
what the sub-make actually gets invoked with. We can guess, but it may
help to be entirely clear !
Follow-up Comment #6, bug #40241 (project make):
My patch did had 2 conceptual problems, sorry.
Please try this patch instead.
(file #29434)
___
Additional Item Attachment:
File name: w32_unixy_shell.difSize:2 KB
On Mon, Oct 21, 2013 at 04:02:58PM +, Edward Welbourne wrote:
It's the long one (subdir-dtc) where the problem exists.
Obvious first step: configure quiet-command to actually show the
command, or remove this wrapping from the command, so that you can see
what the sub-make actually gets
On Mon, 2013-10-21 at 17:36 +0100, Ken Moffat wrote:
I haven't even figured out where quiet-command is located. I'm
only an integration monkey, checking that everything in our distro
(BLFS) will build with make-4.0. Will take a look.
Please see my second email, from earlier today.
Based on
On Mon, 2013-10-21 at 18:03 +0100, Ken Moffat wrote:
2. Unfortunately, rules.mak *is* adding -rR to the MAKEFLAGS -
# Don't use implicit rules or variables
# we have explicit rules for everything
MAKEFLAGS += -rR
I'll attach rules.mak. Is this a qemu bug which just happened to
work in
On Mon, 2013-10-21 at 16:02 +0100, Ken Moffat wrote:
# command line
ARFLAGS =
So this tells us that the empty value is being set from the command
line.
I then ran it in the directory where the build fails (dtc/) -
# makefile (from 'Makefile', line 51)
ARFLAGS = rc
This is not
On Mon, Oct 21, 2013 at 01:11:47PM -0400, Paul Smith wrote:
On Mon, 2013-10-21 at 18:03 +0100, Ken Moffat wrote:
2. Unfortunately, rules.mak *is* adding -rR to the MAKEFLAGS -
# Don't use implicit rules or variables
# we have explicit rules for everything
MAKEFLAGS += -rR
I'll
On Mon, Oct 21, 2013 at 12:51:11PM -0400, Paul Smith wrote:
On Mon, 2013-10-21 at 17:36 +0100, Ken Moffat wrote:
I haven't even figured out where quiet-command is located. I'm
only an integration monkey, checking that everything in our distro
(BLFS) will build with make-4.0. Will take a
On Mon, 2013-10-21 at 18:48 +0100, Ken Moffat wrote:
Thanks. Is it OK if I quote this whole reply to the qemu devs ?
Of course. This mailing list is publicly archived; quote away.
Or point them to the thread:
http://lists.gnu.org/archive/html/bug-make/2013-10/msg00151.html
On Sun, Oct 20, 2013 at 11:58:00PM -0400, Paul Smith wrote:
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
Follow-up Comment #7, bug #40241 (project make):
Without testing this patch I know I'll probably have trouble with it, as
$SHELL doesn't handle quotes right and I'm setting BATCH_MODE_ONLY_SHELL,
which your patch ignores for those.
___
I'm using a complex non-recursive make system to run test suites, some
subset of which are performance tests which should not run in
parallel.
Is there any way to get gmake to run a job serially? Ideally something like:
mytarget: .NOTPARALLEL
Currently I'm forced to either break up the test
Follow-up Comment #8, bug #40241 (project make):
What does doesn't handle quotes right mean? It's a Unixy shell, right?
What kind of shell are you using?
BATCH_MODE_ONLY_SHELL cannot be catered to at this stage, it's something
considered at a higher level. But that higher level doesn't know
Follow-up Comment #9, bug #40241 (project make):
I'm using a msys bash shell, and i'm having problems with it unless I set
BATCH_MODE_ONLY_SHELL.
AFAICT, the patch I attached makes things use BATCH_MODE_ONLY_SHELL as I'd
expect, so it works for me. I don't know why you don't want to hook at that
On Mon, Oct 21, 2013 at 02:06:14PM -0400, Paul Smith wrote:
On Mon, 2013-10-21 at 18:48 +0100, Ken Moffat wrote:
Thanks. Is it OK if I quote this whole reply to the qemu devs ?
Of course. This mailing list is publicly archived; quote away.
Or point them to the thread:
Follow-up Comment #10, bug #40241 (project make):
I actually tested the patch with MSYS Bash. Can you show me one or two
examples of it mishandling quotes? I use MSYS Bash quite a lot (although not
from the native Make), and never saw any problems with quotes.
And, btw, if you use MSYS Bash,
URL:
http://savannah.gnu.org/bugs/?40344
Summary: Can't handle Windows long path names
Project: make
Submitted by: glandium
Submitted on: Tue 22 Oct 2013 04:49:10 AM GMT
Severity: 3 - Normal
Item Group: Bug
Follow-up Comment #5, bug #40322 (project make):
As a matter of fact, we do have an intermediate process for those commands.
I'll double check what's actually happening.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?40322
Follow-up Comment #11, bug #40241 (project make):
Why not msys make? First, because i haven't found an msys make 4.0 build, and
using msys make has its own quirks that are best avoided entirely.
Why /usr/bin/touch? Well, it's not actually /usr/bin/touch, it's mostly
/usr/bin/install or others,
22 matches
Mail list logo
