On Sun, 2017-12-03 at 17:39 +0200, Orgad Shaneh wrote:
> On Fri, Jun 23, 2017 at 2:59 AM, Paul Smith wrote:
> > On Tue, 2017-06-20 at 18:20 +0300, Eli Zaretskii wrote:
> > > > Date: Sun, 18 Jun 2017 17:42:51 +0300
> > > > From: Eli Zaretskii
> > > > Cc: alex...@gmail.com, bug-make@gnu.org
> > > >
On Fri, Jun 23, 2017 at 2:59 AM, Paul Smith wrote:
>
> On Tue, 2017-06-20 at 18:20 +0300, Eli Zaretskii wrote:
> > > Date: Sun, 18 Jun 2017 17:42:51 +0300
> > > From: Eli Zaretskii
> > > Cc: alex...@gmail.com, bug-make@gnu.org
> > > > I think the problem is that reap_children() is called after
>
On Tue, 2017-06-20 at 18:20 +0300, Eli Zaretskii wrote:
> > Date: Sun, 18 Jun 2017 17:42:51 +0300
> > From: Eli Zaretskii
> > Cc: alex...@gmail.com, bug-make@gnu.org
> > > I think the problem is that reap_children() is called after
> > > delete_child_targets, so the child jobs can still run
> > >
> Date: Sun, 18 Jun 2017 17:42:51 +0300
> From: Eli Zaretskii
> Cc: alex...@gmail.com, bug-make@gnu.org
>
> > I think the problem is that reap_children() is called after
> > delete_child_targets, so the child jobs can still run
> > while make is trying to delete.
> >
> > Maybe delete_targets sh
On Sun, Jun 18, 2017 at 6:13 PM, Eli Zaretskii wrote:
> > From: Orgad Shaneh
> > Date: Sun, 18 Jun 2017 17:50:56 +0300
> > Cc: bug-make@gnu.org, Alexey Pavlov
> >
> > > I used Sleep(5), and had count of 2 (I had the same with Sleep(50)).
> >
> > That's strange. How many cores do you have on t
> From: Orgad Shaneh
> Date: Sun, 18 Jun 2017 17:50:56 +0300
> Cc: bug-make@gnu.org, Alexey Pavlov
>
> > I used Sleep(5), and had count of 2 (I had the same with Sleep(50)).
>
> That's strange. How many cores do you have on that system?
>
> 4
So that would mean no matter how long you wait,
> From: David Boyce
> Date: Sun, 18 Jun 2017 04:42:43 -0700
> Cc: Eli Zaretskii , Alexey Pavlov , bug-make
>
>
> In the event this patch is used: I think the interleaved-ifdef style is hard
> to read and best avoided. How about
> either separating the Windows and "other" clauses at the top lev
On Sun, Jun 18, 2017 at 2:42 PM, David Boyce
wrote:
> In the event this patch is used: I think the interleaved-ifdef style is
> hard to read and best avoided. How about either separating the Windows and
> "other" clauses at the top level or something like this (with suitable
> comment):
>
> +
On Sun, Jun 18, 2017 at 5:42 PM, Eli Zaretskii wrote:
> > From: Orgad Shaneh
> > Date: Sun, 18 Jun 2017 08:02:21 +0300
> > Cc: bug-make@gnu.org, Alexey Pavlov
> >
> > Please try the same, but with Sleep calls using 10 or even 5 msec (and
> > enlarging the loop count if necessary). I'd be inte
> From: Orgad Shaneh
> Date: Sun, 18 Jun 2017 08:02:21 +0300
> Cc: bug-make@gnu.org, Alexey Pavlov
>
> Please try the same, but with Sleep calls using 10 or even 5 msec (and
> enlarging the loop count if necessary). I'd be interested to see the
> statistics of the count after which the unlink
In the event this patch is used: I think the interleaved-ifdef style is
hard to read and best avoided. How about either separating the Windows and
"other" clauses at the top level or something like this (with suitable
comment):
+ for (e = 0; e < 10; ++e)
+{
+ status = unlink
On Sun, Jun 18, 2017 at 5:31 AM, Eli Zaretskii wrote:
> > From: Orgad Shaneh
> > Date: Sat, 17 Jun 2017 23:04:11 +0300
> > Cc: bug-make@gnu.org, Alexey Pavlov
> >
> > +#ifdef WINDOWS32
> > + for (e = 0; e < 10; ++e)
> > +{
> > +#endif
> > + status = unlink (file->name);
>
> From: Orgad Shaneh
> Date: Sat, 17 Jun 2017 23:04:11 +0300
> Cc: bug-make@gnu.org, Alexey Pavlov
>
> +#ifdef WINDOWS32
> + for (e = 0; e < 10; ++e)
> +{
> +#endif
> + status = unlink (file->name);
> +#ifdef WINDOWS32
> + if (status == 0 || errno == ENOENT)
> +
On Fri, Jun 16, 2017 at 7:36 PM, Eli Zaretskii wrote:
> > From: Orgad Shaneh
> > Date: Fri, 16 Jun 2017 17:05:58 +0300
> > Cc: "bug-make@gnu.org" , Alexey Pavlov <
> alex...@gmail.com>
> >
> > Ah, okay. But then the problem is not with child processes of g++,
> > it's with g++ itself, right?
>
> From: Orgad Shaneh
> Date: Fri, 16 Jun 2017 17:05:58 +0300
> Cc: "bug-make@gnu.org" , Alexey Pavlov
>
> Ah, okay. But then the problem is not with child processes of g++,
> it's with g++ itself, right?
>
> The child process cc1plus has the file open for writing, and g++ and make
> fail to
On Friday, June 16, 2017, Eli Zaretskii wrote:
> > From: Orgad Shaneh >
> > Date: Fri, 16 Jun 2017 15:59:09 +0300
> > Cc: bug-make@gnu.org
> >
> > I don't see any calls to DeleteFile in this log. I expected to see at
> > least one that failed with ERROR_ACCESS_DENIED. What am I missing?
> >
>
On Friday, June 16, 2017, Eli Zaretskii > wrote:
> > Date: Fri, 16 Jun 2017 16:15:31 +0300
> > From: Eli Zaretskii
> > Cc: bug-make@gnu.org
> >
> > > Ok, I was able to create a minimal example. It happens only with g++
> -pipe.
> >
> > Thanks, but I couldn't reproduce the problem on my main devel
> From: Orgad Shaneh
> Date: Fri, 16 Jun 2017 15:59:09 +0300
> Cc: bug-make@gnu.org
>
> I don't see any calls to DeleteFile in this log. I expected to see at
> least one that failed with ERROR_ACCESS_DENIED. What am I missing?
>
> There is SHARING_VIOLATION for both g++.exe and mingw32-make.ex
> Date: Fri, 16 Jun 2017 16:15:31 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> > Ok, I was able to create a minimal example. It happens only with g++ -pipe.
>
> Thanks, but I couldn't reproduce the problem on my main development
> machine.
Correction: I do succeed sometimes to reprodu
> From: Orgad Shaneh
> Date: Fri, 16 Jun 2017 14:24:13 +0300
> Cc: bug-make@gnu.org
>
> Ok, I was able to create a minimal example. It happens only with g++ -pipe.
Thanks, but I couldn't reproduce the problem on my main development
machine. In my case, Make succeeds to delete the file every tim
On Fri, Jun 16, 2017 at 3:52 PM, Eli Zaretskii wrote:
> > From: Orgad Shaneh
> > Date: Fri, 16 Jun 2017 11:49:33 +0300
> > Cc: bug-make@gnu.org
> >
> > In general, killing subprocesses is problematic on Windows, because
> > only child processes can be killed, the grandchildren cannot.
> > The
> From: Orgad Shaneh
> Date: Fri, 16 Jun 2017 11:49:33 +0300
> Cc: bug-make@gnu.org
>
> In general, killing subprocesses is problematic on Windows, because
> only child processes can be killed, the grandchildren cannot.
> Therefore, rearranging your build commands might make the issue go
> aw
> From: Orgad Shaneh
> Date: Fri, 16 Jun 2017 11:49:33 +0300
> Cc: bug-make@gnu.org
>
> I'd certainly like to know why "setlocale interferes with line
> buffering if using parallel make on MinGW". Could you perhaps ask the
> MSYS2 maintainers to report their findings here or on make-w32?
>
>
On Fri, Jun 16, 2017 at 11:49 AM, Orgad Shaneh wrote:
> On Fri, Jun 16, 2017 at 9:23 AM, Eli Zaretskii wrote:
>
>> > From: Orgad Shaneh
>> > Date: Fri, 16 Jun 2017 00:46:34 +0300
>> >
>> > Ok, I found out that the bug is not (entirely) in make. What causes
>> this problem is the following patch
On Fri, Jun 16, 2017 at 9:06 AM, Eli Zaretskii wrote:
> > From: Orgad Shaneh
> > Date: Thu, 15 Jun 2017 22:33:30 +0300
> >
> > When I abort a build, make fails to unlink the intermediate files. I
> previously used 4.1.90, and I don't remember
> > having these problems.
> >
> > This happens even
On Fri, Jun 16, 2017 at 9:23 AM, Eli Zaretskii wrote:
> > From: Orgad Shaneh
> > Date: Fri, 16 Jun 2017 00:46:34 +0300
> >
> > Ok, I found out that the bug is not (entirely) in make. What causes this
> problem is the following patch applied
> > by MSYS2 packages of mingw make:
> >
> > diff -Naur
On Fri, 16 Jun 2017 01:16:09 +0300
Orgad Shaneh wrote:
> > On Thu, Jun 15, 2017 at 10:33 PM, Orgad Shaneh
> > wrote:
> >> mingw32-make[1]: *** Deleting file 'obj/main.o'
> >> mingw32-make[1]: unlink: obj/main.o: Permission denied
> Another thing I've noticed is that make (on Windows/MinGW) leav
> From: Orgad Shaneh
> Date: Fri, 16 Jun 2017 01:16:09 +0300
>
> ... or not. I still get it even without this patch, when running from IDE.
> Reverting the patch only fixes the issue
> when running in command line.
>
> I did file a bug[1], but this is not the real reason. Probably timing issue.
> From: Orgad Shaneh
> Date: Fri, 16 Jun 2017 00:46:34 +0300
>
> Ok, I found out that the bug is not (entirely) in make. What causes this
> problem is the following patch applied
> by MSYS2 packages of mingw make:
>
> diff -Naur make-4.2.1/main.c make-4.2.1.new/main.c
> --- make-4.2.1/main.c 20
> From: Orgad Shaneh
> Date: Thu, 15 Jun 2017 22:33:30 +0300
>
> When I abort a build, make fails to unlink the intermediate files. I
> previously used 4.1.90, and I don't remember
> having these problems.
>
> This happens even for a single job (without -j).
>
> Output:
> main.cpp
> mingw32-ma
On Friday, June 16, 2017, Henrik Carlqvist wrote:
> On Fri, 16 Jun 2017 01:16:09 +0300
> Orgad Shaneh > wrote:
>
> > > On Thu, Jun 15, 2017 at 10:33 PM, Orgad Shaneh >
> > > wrote:
> > >> mingw32-make[1]: *** Deleting file 'obj/main.o'
> > >> mingw32-make[1]: unlink: obj/main.o: Permission denie
On Fri, Jun 16, 2017 at 12:46 AM, Orgad Shaneh wrote:
> On Thu, Jun 15, 2017 at 10:33 PM, Orgad Shaneh wrote:
>
>> Hi,
>>
>> I'm using mingw32-make 4.2.1 from MSYS2/mingw32.
>>
>> When I abort a build, make fails to unlink the intermediate files. I
>> previously used 4.1.90, and I don't remember
On Thu, Jun 15, 2017 at 10:33 PM, Orgad Shaneh wrote:
> Hi,
>
> I'm using mingw32-make 4.2.1 from MSYS2/mingw32.
>
> When I abort a build, make fails to unlink the intermediate files. I
> previously used 4.1.90, and I don't remember having these problems.
>
> This happens even for a single job (w
Hi,
I'm using mingw32-make 4.2.1 from MSYS2/mingw32.
When I abort a build, make fails to unlink the intermediate files. I
previously used 4.1.90, and I don't remember having these problems.
This happens even for a single job (without -j).
Output:
main.cpp
mingw32-make[1]: *** Deleting file 'obj
34 matches
Mail list logo
