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.
URL:
http://savannah.gnu.org/bugs/?34830
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
URL:
http://savannah.gnu.org/bugs/?34832
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
Item
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
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
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:
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
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 code
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.
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
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 it
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
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
URL:
http://savannah.gnu.org/bugs/?34818
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
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
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 or
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.
___
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
On Fri, Jul 9, 2010 at 1:00 PM, Eli Zaretskii e...@gnu.org wrote:
Date: Mon, 05 Jul 2010 21:42:52 +0300
From: Eli Zaretskii e...@gnu.org
Cc: seze...@gmail.com, bo...@kolpackov.net, bug-make@gnu.org
From: Paul D. Smith invalid.nore...@gnu.org
Date: Mon, 05 Jul 2010 18:32:15 +
On Fri, Jul 9, 2010 at 1:00 PM, Eli Zaretskii e...@gnu.org wrote:
Date: Mon, 05 Jul 2010 21:42:52 +0300
From: Eli Zaretskii e...@gnu.org
Cc: seze...@gmail.com, bo...@kolpackov.net, bug-make@gnu.org
From: Paul D. Smith invalid.nore...@gnu.org
Date: Mon, 05 Jul 2010 18:32:15 +
On Fri, Jul 9, 2010 at 1:17 PM, Ozkan Sezer seze...@gmail.com wrote:
On Fri, Jul 9, 2010 at 1:00 PM, Eli Zaretskii e...@gnu.org wrote:
Date: Mon, 05 Jul 2010 21:42:52 +0300
From: Eli Zaretskii e...@gnu.org
Cc: seze...@gmail.com, bo...@kolpackov.net, bug-make@gnu.org
From: Paul D. Smith
On Fri, Jul 9, 2010 at 2:14 PM, Eli Zaretskii e...@gnu.org wrote:
From: Ozkan Sezer invalid.nore...@gnu.org
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 e...@gnu.org wrote:
From: Paul D. Smith
On Fri, Jul 9, 2010 at 1:30 PM, Eli Zaretskii e...@gnu.org wrote:
Date: Fri, 9 Jul 2010 13:18:12 +0300
From: Ozkan Sezer seze...@gmail.com
Cc: bug-make@gnu.org, bo...@kolpackov.net
On Fri, Jul 9, 2010 at 1:17 PM, Ozkan Sezer seze...@gmail.com wrote:
On Fri, Jul 9, 2010 at 1:00 PM, Eli
On Fri, Jul 9, 2010 at 3:05 PM, Eli Zaretskii e...@gnu.org 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
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
Follow-up Comment #8, bug #27809 (project make):
On Mon, Jul 5, 2010 at 1:35 PM, Edward Welbourne e...@opera.com 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
On Mon, Jul 5, 2010 at 1:35 PM, Edward Welbourne e...@opera.com 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
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
Follow-up Comment #11, bug #27809 (project make):
On Mon, Jul 5, 2010 at 9:42 PM, Eli Zaretskii e...@gnu.org wrote:
From: Paul D. Smith invalid.nore...@gnu.org
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
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:
http://savannah.gnu.org/bugs/?27825
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
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). Which
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]:
URL:
http://savannah.gnu.org/bugs/?27825
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
URL:
http://savannah.gnu.org/bugs/?27809
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
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
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 one.
On Mon, Oct 26, 2009 at 10:49 PM, Eli Zaretskii e...@gnu.org wrote:
From: Ozkan Sezer invalid.nore...@gnu.org
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
On Mon, Oct 26, 2009 at 11:21 PM, Ozkan Sezer seze...@gmail.com wrote:
On Mon, Oct 26, 2009 at 10:47 PM, Eli Zaretskii e...@gnu.org wrote:
From: Ozkan Sezer invalid.nore...@gnu.org
Date: Mon, 26 Oct 2009 19:20:27 +
3. Why did you need casts in assignments, like this:
- *pid_p
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 are casting a
40 matches
Mail list logo
