[bug #27809] several win64 fixes

2009-10-26 Thread Ozkan Sezer
Follow-up Comment #4, bug #27809 (project make): [ I forgot replying from within the bug tracker. sorry if this becomes a duplicate. ] >> > 3. Why did you need casts in assignments, like this: >> > >> > -*pid_p = (int) hProcess; >> > +*pid_p = (pid_t) hProcess; >> > >> >> Because you a

Re: [bug #27809] several win64 fixes

2009-10-26 Thread Ozkan Sezer
On Mon, Oct 26, 2009 at 11:21 PM, Ozkan Sezer wrote: > On Mon, Oct 26, 2009 at 10:47 PM, Eli Zaretskii wrote: >>> From: Ozkan Sezer >>> Date: Mon, 26 Oct 2009 19:20:27 + >>> >>> >>> > 3. Why did you need casts in assignments, like this: >>> > >>> > -    *pid_p = (int) hProcess; >>> > +    *p

Re: [bug #27809] several win64 fixes

2009-10-26 Thread Ozkan Sezer
On Mon, Oct 26, 2009 at 10:49 PM, Eli Zaretskii wrote: >> From: Ozkan Sezer >> Date: Mon, 26 Oct 2009 20:27:27 + >> >> >> -mthreads :  This one is a noop for mingw-w64 crt. > > This is needed to properly handle Ctrl-C, since (at least on w32) the > signal handler runs in a separate thread.  S

Re: [bug #27809] several win64 fixes

2009-10-26 Thread Ozkan Sezer
On Mon, Oct 26, 2009 at 10:47 PM, Eli Zaretskii wrote: >> From: Ozkan Sezer >> Date: Mon, 26 Oct 2009 19:20:27 + >> >> >> > 3. Why did you need casts in assignments, like this: >> > >> > -    *pid_p = (int) hProcess; >> > +    *pid_p = (pid_t) hProcess; >> > >> >> Because you are casting a ha

RE: [bug #27809] several win64 fixes

2009-10-26 Thread Martin Dorey
> why can't you get rid of the cast altogether Because there is no implicit conversion from pointer to integer. > users of MinGW will then complain about compiler warnings, right? Because of an implicit conversion from unsigned int (the definition of uintptr_t on w32) to long, on a platform wher

Re: [bug #27809] several win64 fixes

2009-10-26 Thread Eli Zaretskii
> From: Ozkan Sezer > Date: Mon, 26 Oct 2009 20:27:27 + > > > -mthreads : This one is a noop for mingw-w64 crt. This is needed to properly handle Ctrl-C, since (at least on w32) the signal handler runs in a separate thread. So what happens in a w64 build of Make if you press Ctrl-C while

Re: [bug #27809] several win64 fixes

2009-10-26 Thread Eli Zaretskii
> From: Ozkan Sezer > Date: Mon, 26 Oct 2009 19:20:27 + > > > > 3. Why did you need casts in assignments, like this: > > > > -*pid_p = (int) hProcess; > > +*pid_p = (pid_t) hProcess; > > > > Because you are casting a handle, which is a ptr*, to an int. But you change pid_p to poin

[bug #27809] several win64 fixes

2009-10-26 Thread Ozkan Sezer
Follow-up Comment #3, bug #27809 (project make): >> 5. Finally, could you please see if the build_w32.bat script works for a >> 64-bit MinGW GCC? If you see problems there, please report them. > > I did all my work on linux, cross-compiling for w64. When I reboot into > windows, I can try that

[bug #27809] several win64 fixes

2009-10-26 Thread Ozkan Sezer
Follow-up Comment #2, bug #27809 (project make): > 1. What versions of GCC and of MinGW runtime did you use to build Make? Gcc version: gcc-4.4.3 prerelease. MinGW runtime, however, seems as the confusion here: mingw.org does not support win64. however the mingw-w64 project, (sf.net project p

[bug #27809] several win64 fixes

2009-10-26 Thread Eli Zaretskii
Follow-up Comment #1, bug #27809 (project make): Thank you for your contribution. I have a few questions for the patches you sent: 1. What versions of GCC and of MinGW runtime did you use to build Make? 2. Which header defines pid_t as appropriate for both 32-bit and 64-bit Windows? What is t

[bug #27809] several win64 fixes

2009-10-26 Thread Ozkan Sezer
URL: Summary: several win64 fixes Project: make Submitted by: sezero Submitted on: Mon 26 Oct 2009 09:07:56 AM GMT Severity: 3 - Normal Item Group: Bug