[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 #34830] minor windows fixes

Follow-up Comment #5, bug #34830 (project make): I already had a local fix for the configure disable thing; I was just waiting to be sure the variable change worked for you. Committed the changes so please try the latest. ___ Reply to this

[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 #3, bug #34830 (project make): Well, I can't test it because I have no Windows tools Anyway the case statement is right. What it's trying to ask is if ANY value in the list is "no". The "*" will match zero or more chars, so this says, basically, if the string "/no/" appears an

[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

Update of bug #34830 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[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 #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #19, bug #34832 (project make): You can provide a stack buffer from the caller like char * tmp[1000]; fprintf(..., map_windows32_error_to_string (tmp, er)); And the functions that call map_windows32_error_to_string from threads are not used. ___

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

Follow-up Comment #18, bug #34832 (project make): All the uses pointed out by Paul are from a single thread. The only problem, if there is one, is with the calls from sub_proc.c. As for TLS availability for MSVC being a proof that it works, I have my doubts: with most of calls to the function co

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

Follow-up Comment #17, bug #34832 (project make): It is used: make-cvs$ grep map_windows32_error_to_string *.c commands.c:ierr, map_windows32_error_to_string (ierr)); job.c: error_string = map_windows32_error_to_string (er); job.c: e, map_w

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

Follow-up Comment #16, bug #34832 (project make): You can't easily simulate errors in a function that is not used from anywhere. ___ Reply to this item at: __

[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 #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 #13, 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 uncomment

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

Follow-up Comment #12, bug #34832 (project make): The reason the buffer is static is that if you allocate a dynamic buffer, someone has to free it. In POSIX we use the strerror() function which returns a const pointer to a static string that never needs to be freed so there's no facility in the c

[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 #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 #8, bug #34832 (project make): Paul, The Windows build of Make does use more than a single thread. Ozkan, Yes, I know that functions in the top-level directory call map_windows32_error_to_string, but those functions all run in a single thread. The only functions that don't ar

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

Follow-up Comment #7, bug #34832 (project make): That function is used a lot in job.c, main.c, commands.c. But I agree with Eli: what's the need for having this variable be thread-safe in the first place? GNU make is not multithreaded (there would be a LOT of work needed to make that possible).

[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 #5, bug #34832 (project make): Which multiple threads in Make might try to access the same static buffer concurrently? And under what circumstances? All but one call to map_windows32_error_to_string in sub_proc.c are commented out.

[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 #3, bug #34832 (project make): Thanks. I know what TLS means. I meant to ask why it is useful for map_windows32_error_to_string to use thread local storage? What will that gain for Make? The comment there said it was only needed for MSVC. ___

[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 #1, bug #34832 (project make): Thanks. However, you didn't explain what does this patch try to accomplish, and there's no ChangeLog entry in sight to help me understand that. Could you please describe the rationale? Also, please don't make gratuitous changes of whitespace, the

[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 #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