On Thu, Nov 3, 2022 at 8:07 AM Eli Zaretskii wrote:
>
> > From: Orgad Shaneh
> > Date: Wed, 2 Nov 2022 22:14:26 +0200
> > Cc: bug-make@gnu.org
> >
> > On Wed, Nov 2, 2022 at 7:04 PM Eli Zaretskii wrote:
> > > > Fix by enabling _stat64 also for MinGW
On Wed, Nov 2, 2022 at 7:04 PM Eli Zaretskii wrote:
> > Fix by enabling _stat64 also for MinGW.
>
> Thanks, but this cannot be done for all MinGW builds. There's
> mingw.org's MinGW (which is what I use), and its default is to use
> 32-bit time_t values. If you use this change with that MinGW, M
Commit 01142a53c9d (Add support for intmax_t) added support for 64-bit
time_t by defining __MINGW_USE_VC2005_COMPAT. But this only works with
_stat64 as expected. When stat is used on 32-bit systems, it returns a
bad timestamp (for example, 72586185920376753).
This triggers the following errors ev
Hi,
I have several patches that are required for making the build pass.
I'm not sure what's the typical way you handle patches. I sent one of the
patches yesterday using git send-email, but I'm not sure that's the way you
expect it.
Please review the attached patches. They are independent, but a
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 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)).
> >
> >
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
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)
> > +{
> >
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 p
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
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
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
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. Wh
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 the
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 pac
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'
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.
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.
>
>
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
On Tue, Jun 6, 2017 at 9:43 PM, Eli Zaretskii wrote:
>> From: Orgad Shaneh
>> Date: Tue, 6 Jun 2017 20:49:26 +0300
>> Cc: bug-make@gnu.org
>>
>> > Can you tell why this is a problem? There's no equivalent of PATHEXT
>> > on Posix systems, and n
On Tue, Jun 6, 2017 at 8:18 PM, Eli Zaretskii wrote:
>> From: Orgad Shaneh
>> Date: Mon, 5 Jun 2017 23:13:26 +0300
>>
>> 1 You must use a full name for SHELL, including the extension (SHELL=sh
>> doesn't work. SHELL=sh.exe
>> does, if sh.exe exists
I have 3 problems with SHELL assignment on Windows (mingw32-make):
1. You must use a full name for SHELL, including the extension (SHELL=sh
doesn't work. SHELL=sh.exe does, if sh.exe exists in PATH). PATHEXT should
be used for the executable detection.
2. It looks like if PATH contain
23 matches
Mail list logo
