[bug #27809] several win64 fixes

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

[bug #27809] several win64 fixes

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

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

Re: [bug #27809] several win64 fixes

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; >> > +    *pi

Re: [bug #27809] several win64 fixes

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 > s

Re: [bug #27809] several win64 fixes

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,

[bug #27809] several win64 fixes

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

[bug #27825] win64 fix for config.h.W32.template

URL: Summary: win64 fix for config.h.W32.template Project: make Submitted by: sezero Submitted on: Tue 27 Oct 2009 02:35:56 PM GMT Severity: 3 - Normal Item Group: None

[bug #29025] problem with odd directory names with spaces and/or parentheses

URL: Summary: problem with odd directory names with spaces and/or parentheses Project: make Submitted by: sezero Submitted on: Sun 28 Feb 2010 10:35:47 AM GMT Severity: 3 - Normal

[bug #29025] problem with odd directory names with spaces and/or parentheses

Additional Item Attachment, bug #29025 (project make): File name: SubDirSpaces.tar.gzSize:0 KB ___ Reply to this item at: ___ Message sent

[bug #29025] problem with odd directory names with spaces and/or parentheses

Follow-up Comment #1, bug #29025 (project make): FWIW, I am attaching the original SubDirSpaces directory from the cmake test failure report at http://sourceforge.net/projects/mingw-w64/forums/forum/723798/topic/3551522 The original error message, as reported to me is the following: "gmake[2]: E

[bug #27809] several win64 fixes

Follow-up Comment #5, bug #27809 (project make): Here is a follow-up patch (make-cvs-20100701-w64-2.patch) which fixes a lot of compiler warnings, not only for mingw* but for unix, too. (file #20896) ___ Additional Item Attachment: File n

[bug #27825] win64 fix for config.h.W32.template

Follow-up Comment #1, bug #27825 (project make): Also see bug #27809 for more win64 issues and proposed fixes. ___ Reply to this item at: ___ Message s

[bug #27809] several win64 fixes

Follow-up Comment #7, bug #27809 (project make): Paul, thank you very much for reviewing the patch, > First you mention compiler warning fixes for UNIX, but > none of the changes you mention fix any warnings I see > on my UNIX tests (different platforms but using gcc -Wall > on all of them). Wh

[bug #27809] several win64 fixes

Follow-up Comment #8, bug #27809 (project make): On Mon, Jul 5, 2010 at 1:35 PM, Edward Welbourne wrote: [snip] >> Finally, it seems that some of these changes are meant to >> avoid variable names conflicting with function names (open, >> etc.) Is this really a warning that some compilers give?

Re: [bug #27809] several win64 fixes

On Mon, Jul 5, 2010 at 1:35 PM, Edward Welbourne wrote: [snip] >> Finally, it seems that some of these changes are meant to avoid variable >> names conflicting with function names (open, etc.)  Is this really a warning >> that some compilers give? > > Even gcc has a flag for it: -Wshadow; I conjec

[bug #27809] several win64 fixes

Follow-up Comment #10, bug #27809 (project make): > I've applied most of the second patch. The first patch is Thanks. > I did have one question about the first patch: you have a > change to make.h which adds an include of malloc.h, but > later in make.h that header is already included if WINDO

[bug #27809] several win64 fixes

Follow-up Comment #11, bug #27809 (project make): On Mon, Jul 5, 2010 at 9:42 PM, Eli Zaretskii wrote: >> From: "Paul D. Smith" >> Date: Mon, 05 Jul 2010 18:32:15 + >> >> I've applied most of the second patch. The first patch is >> mostly in the w32 area so maybe Eli is a better person to

[bug #27825] win64 fix for config.h.W32.template

Follow-up Comment #2, bug #27825 (project make): The suggested change is moved to a new patch in bug #27809. This particular entry can be closed. ___ Reply to this item at:

Re: [bug #27809] several win64 fixes

On Fri, Jul 9, 2010 at 1:00 PM, Eli Zaretskii wrote: >> Date: Mon, 05 Jul 2010 21:42:52 +0300 >> From: Eli Zaretskii >> Cc: seze...@gmail.com, bo...@kolpackov.net, bug-make@gnu.org >> >> > From: "Paul D. Smith" >> > Date: Mon, 05 Jul 2010 18:32:15 + >> > >> > >> > Follow-up Comment #9, bug #

Re: [bug #27809] several win64 fixes

On Fri, Jul 9, 2010 at 1:00 PM, Eli Zaretskii wrote: >> Date: Mon, 05 Jul 2010 21:42:52 +0300 >> From: Eli Zaretskii >> Cc: seze...@gmail.com, bo...@kolpackov.net, bug-make@gnu.org >> >> > From: "Paul D. Smith" >> > Date: Mon, 05 Jul 2010 18:32:15 + >> > >> > >> > Follow-up Comment #9, bug #

Re: [bug #27809] several win64 fixes

On Fri, Jul 9, 2010 at 1:17 PM, Ozkan Sezer wrote: > On Fri, Jul 9, 2010 at 1:00 PM, Eli Zaretskii wrote: >>> Date: Mon, 05 Jul 2010 21:42:52 +0300 >>> From: Eli Zaretskii >>> Cc: seze...@gmail.com, bo...@kolpackov.net, bug-make@gnu.org >>> >>>

Re: [bug #27809] several win64 fixes

On Fri, Jul 9, 2010 at 2:14 PM, Eli Zaretskii wrote: >> From: Ozkan Sezer >> Date: Mon, 05 Jul 2010 19:58:04 + >> >> >> Follow-up Comment #11, bug #27809 (project make): >> >> On Mon, Jul 5, 2010 at 9:42 PM, Eli Zaretskii wrote: >> >>

Re: [bug #27809] several win64 fixes

On Fri, Jul 9, 2010 at 1:30 PM, Eli Zaretskii wrote: >> Date: Fri, 9 Jul 2010 13:18:12 +0300 >> From: Ozkan Sezer >> Cc: bug-make@gnu.org, bo...@kolpackov.net >> >> On Fri, Jul 9, 2010 at 1:17 PM, Ozkan Sezer wrote: >> > On Fri, Jul 9, 2010 at 1:00 PM, Eli

Re: [bug #27809] several win64 fixes

On Fri, Jul 9, 2010 at 3:05 PM, Eli Zaretskii wrote: [snip] >> > Thanks.  I used almost all of the patches in w64-all-20100705.diff. >> > >> >> Thanks for applying the patches. >> >> There are some issues, though: > > I forgot to send these upstream, now fixed. > Thanks. In make.h, the w32_kill

[bug #27809] several win64 fixes

Follow-up Comment #14, bug #27809 (project make): In its current state the CVS doesn't build for windows targets, because the protoype for w32_kill isn't updated to match job.c. I think Eli is aware of it but I am posting this so that things do not get forgotten. And while I am here, here are so

small patches submitted to savannah patch tracker

Hi: I submitted several small patches to savannah patch tracker. That tracker looks like not being visited much, so I thought that a notification here wouldn't hurt. [patch #7240] cast const pointers to void* when feeding them to free(), qsort() or realloc() http://savannah.gnu.org/patch/?7240

[bug #34818] PATH_SEPARATOR_CHAR broken for windows when cross-compiled

URL: Summary: PATH_SEPARATOR_CHAR broken for windows when cross-compiled Project: make Submitted by: sezero Submitted on: Mon 14 Nov 2011 11:04:23 AM GMT Severity: 3 - Normal

[bug #34818] PATH_SEPARATOR_CHAR broken for windows when cross-compiled

Follow-up Comment #2, bug #34818 (project make): > A slightly cleaner implementation might have PATH_SEPARATOR_CHAR > defined in the various target-specific config.h files on systems > that don't support autoconf, ... Autoconf _is_ the problem here, because its PATH_SEP detection is not cross-com

[bug #34818] PATH_SEPARATOR_CHAR broken for windows when cross-compiled

Follow-up Comment #4, bug #34818 (project make): > ... For typical Windows, VMS, OS2, etc. builds GNU make doesn't > run autotools (as I understand it). Well, _need_ not run autotools, if one is lazy or especially when building on the native OS itself, provided that he has his own build scripts o

[bug #34818] PATH_SEPARATOR_CHAR broken for windows when cross-compiled

Follow-up Comment #6, bug #34818 (project make): > Cross-compiling for a Windows target sounds funky > to me but I definitely see the attraction there :-) Yep :) I, for one, compile 95% of times on linux rather than on windows or djgpp. __

[bug #34830] minor windows fixes

URL: Summary: minor windows fixes Project: make Submitted by: sezero Submitted on: Tue 15 Nov 2011 01:47:52 PM GMT Severity: 3 - Normal Item Group: None

[bug #34832] enable tls variable in windows code for newish gcc

URL: Summary: enable tls variable in windows code for newish gcc Project: make Submitted by: sezero Submitted on: Tue 15 Nov 2011 04:06:15 PM GMT Severity: 3 - Normal Ite

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #2, bug #34832 (project make): The patch enables thread local storage in map_windows32_error_to_string() not only for MSVC, but also for gcc-built make binaries. It also constifies the returned value from the function, because the returned string is always used as read-only argum

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #4, bug #34832 (project make): Because at the time that code was writtten, a __declspec(thread) equivalent wasn't available for gcc: that's the original author's skills in making a useful comment you are seeing. TLS is obviously necessary for that static array to make multiple t

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #6, bug #34832 (project make): Are you looking at code from 1996? Have ever you tried grepping under top level *.c files for map_windows32_error_to_string ? ___ Reply to this item at:

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #9, bug #34832 (project make): Then __declspec(thread) isn't actually needed, not for msvc, not for gcc either. As for thread-safety, I first though that that I caught glimpses of CreateThread(), but hmm, those turned out to be CreateProcess(). There are calls to _beginthreade

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #11, bug #34832 (project make): > Why don't you rewrite the code do get rid of that static buffer > in the first place. That's certainly a good idea (had we known who you are, it would been even better, I guess.) Another cleanup would be removing the pointless winsock error cod

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #14, bug #34832 (project make): > if the benefits are worth the complexity. IMO, _definitely_ not. Side notes: the winsock errors check can definitely be removed from there along with the tls usage for msvc special case. And the function needs returning const.

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #15, bug #34832 (project make): > We could get rid of that static buffer, or we could use the > __thread declaration, but my point is: if we are enabling to > produce error message strings from several threads, we might > as well actually do that and see that it works, e.g., by >

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #20, bug #34832 (project make): > As for TLS availability for MSVC being a proof that it works, > I have my doubts: Well, why the hell is it there, then? I assume you are the one who is supposed to know that, and not me. If it is unnecessary or obsolete or whatever, removing i

[bug #34830] minor windows fixes

Follow-up Comment #2, bug #34830 (project make): Thanks for applying the patches. Hmm, configury still doesn't allow jobserver for windows. Looking around line 305 of configure.in, you are testing four variables but against "*/no/*" i.e. three. Changing to something like: case "$ac_cv_func_pip

[bug #34830] minor windows fixes

Follow-up Comment #4, bug #34830 (project make): Your suggestion works, but --disable-job-server indeed doesn't work. How about the attached suggestion? It is actually an edited form of configure.in r1.157. Works with and without --disable-job-server properly for me. (file #24384, file #24385)

[bug #34830] minor windows fixes

Follow-up Comment #6, bug #34830 (project make): With r1.159, job-server configury for *-*-mingw* works, yes. Thank you. Hopefully nothing is broken for any other targets, with or without --disable-job-server and/or --enable-job-server. For mingw configury, only bug #34818 remains unresolved now

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #22, bug #34832 (project make): Propagating the tls functionality to gcc-builds won't hurt, but as I already said, please just remove it altogether if it isn't helping with anything (which it certainly looks that way) and that will stop any future confusions. ___