Re: bug-report: make does not read Makefile on Windows in case sensitive folder

> From: Espen Ottar > CC: "bug-make@gnu.org" > Date: Mon, 30 Jun 2025 13:39:30 + > > Ok, my bad. I was using make 3.81 from > https://gnuwin32.sourceforge.net/packages/make.htm Try the one from ezwinports site.

Re: bug-report: make does not read Makefile on Windows in case sensitive folder

> From: Espen Ottar > Date: Mon, 30 Jun 2025 07:47:41 + > > On Windows it is possible to enable case sensitivity on a per-folder basis . > (using fsutil.exe) > When case sensitivity is enabled, make fails to read "Makefile" (with capital > M) > The workaround is to use "make -f Makefile" bu

Re: Enabling hi-res timestamps on Windows

> From: Jeffrey Walton > Date: Wed, 19 Feb 2025 09:04:27 -0500 > Cc: Eldred HABERT , bug-make@gnu.org > > On Wed, Feb 19, 2025 at 7:41 AM Eli Zaretskii wrote: > > > > It is not that simple. GNU Make uses 'stat' to retrieve the time > > stamp of fil

Re: Enabling hi-res timestamps on Windows

> Date: Tue, 18 Feb 2025 22:06:11 +0100 (GMT+01:00) > From: Eldred HABERT > > Hello! > > I am having an issue that some versions of Make never stop on a Make file I > made, but only on Windows. > https://github.com/ISSOtm/gb-starter-kit/issues/1#issuecomment-1793775226 > I have traced the issue

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #2, bug #66499 (group make): > Unfortunately I know of no way to determine how large a pipe a system > supports short of filling one up. What about fcntl with F_GETPIPE_SZ? ___ Reply to this item at:

Re: Parallel make across multiple connected systems.

> From: Sean Godsell > Date: Wed, 27 Nov 2024 17:00:27 -0500 > > I was wondering if anyone has any plans to make the actual 'make' command > work across multiple > connected PC systems, via networking of some kind. It could be wireless > networking, ethernet, or even > networking through thund

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

Follow-up Comment #2, bug #66381 (group make): The proposed patch will not work well on MS-Windows: it assumes that '/' is the only possible directory separator character, and it ignores the possibility of a drive letter in file names. I hope these non-portable aspects will be fixed before this e

Re: fixes for unlikely pointer overflow, buffer truncation

> From: Martin Dorey > CC: "bug-make@gnu.org" > Date: Mon, 5 Aug 2024 23:13:47 + > > "Beginning with the UCRT in Visual Studio 2015 and Windows 10, snprintf is no > longer identical to _snprintf. The snprintf behavior is now C99 standard > conformant. The difference is that if you run out

[bug #65777] add const misc global RO arrays

Update of bug #65777 (group make): Severity: 3 - Normal => 1 - Wish Assigned to:None => psmith Component Version:None => SCM Triage Status:

[bug #65776] [PATCH 1/3] win32 STAT_LITE

Follow-up Comment #1, bug #65776 (group make): We don't use GetFileAttributesEx because it doesn't exist on old Windows systems, and GNU Make still wants to support those old systems. So I don't think we should make these changes, sorrty. ___

[bug #65775] [PATCH 2/2] win32 dir.c eliminate OS specific dir-cache agressive reread vs posix

Update of bug #65775 (group make): Assigned to:None => eliz Component Version:None => SCM Triage Status:None => Medium Effort ___

[bug #65774] [PATCH] win32: use link time optimization for Visual C Release build

Update of bug #65774 (group make): Severity: 3 - Normal => 2 - Minor Assigned to:None => eliz Component Version:None => SCM Triage Status:

[bug #65773] [PATCH] win32: on VC always make PDB debugging symbols for Release

Update of bug #65773 (group make): Severity: 3 - Normal => 2 - Minor Assigned to:None => eliz Component Version:None => SCM Triage Status:

[bug #65772] [PATCH] win32: don't twice search disk for $(SHELL) unless PATH or SHELL changed

Update of bug #65772 (group make): Severity: 3 - Normal => 1 - Wish Status:None => Wont Fix Assigned to:None => eliz Component Version:

[bug #65771] [PATCH] restore Visual C 6 and newer but older VC 200X builds

Update of bug #65771 (group make): Severity: 3 - Normal => 2 - Minor Item Group: Enhancement => Build/Install Assigned to:None => eliz Component Version:

Re: [PATCH] src/main.c: Add -J to detect number of job slots based on nproc.

> Date: Fri, 12 Apr 2024 07:58:28 +0200 > From: Henrik Carlqvist > Cc: bug-make@gnu.org, matt.stav.tay...@gmail.com > > On Fri, 12 Apr 2024 02:13:36 +0100 > Matt Staveley-Taylor wrote: > > Browsing the mailing list I can see that the behaviour of -j with no > > arguments has been discussed a few

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #34, bug#64806 (group make): That weird problem is with a particular build of Windows port of GNU Make, and it is not clear to me on what OS the error was seem. But yes, it sounds like it's a separate issue. ___ Reply t

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #32, bug#64806 (group make): I don't think I understand what you mean by "change management aspect", and why the behavior discussed here doesn't have much to do with the original problem report. Please elaborate. ___ Re

[bug #65273] Potential bug in the info function?

Follow-up Comment #5, bug#65273 (group make): FWIW, I think it is very unfortunate that GNU Make started warning about this trick, especially if there is no reasonable way of getting the same effect by other means. ___ Reply to this item

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #30, bug#64806 (group make): Thanks for the footwork and detailed information. This is for Paul to decide, eventually, but I personally would prefer a simpler way of calling osync_clear on MS-Windows only in the top-level Make. AFAIU, this should solve the problem without rockin

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #28, bug#64806 (group make): Thanks, this is important information. So I think the next step is to understand which call to osync_clear closes the handle. Maybe we shouldn't make that call, at least on Windows? Also, this only happens sometimes, right? That is, -Otarget somet

Re: Segmentation Fault on Exported Resursively Expanded Variable

> Date: Tue, 16 Jan 2024 19:21:04 +0100 > From: Henrik Carlqvist > Cc: psm...@gnu.org, bug-make@gnu.org > > On Tue, 16 Jan 2024 06:59:30 + > MIAOW Miao wrote: > > if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0) > > Looking at that line, the rather obvious fix would be to change it

Re: [bug #64806] "invalid output sync mutex" on windows

> Date: Mon, 15 Jan 2024 12:37:42 -0500 > From: Ken Brown > > This is a long shot, but I had a problem a year ago with parallel make > on Cygwin occasionally hanging. The solution turned out to be to force > make's jobserver to use pipes instead of fifos. If you want to try > this, pass make

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #25, bug#64806 (group make): The \Device\ConDrv thing is strange, not sure what to make of that. The one process where the handle is shown as "Mutant" is correct, AFAIU. Maybe it means the child processes actually released the mutex, but then why does the parent keep waiting, an

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #23, bug#64806 (group make): Do any other processes of those involved in the hang have this same mutex handle open? ___ Reply to this item at: __

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #21, bug#64806 (group make): Can you use ProcessExplorer (or some other SysInternals tool) to find out which process, if any holds the handle that is the value of osync_handle, the handle for which osync_acquire is waiting in the instances that are hung? __

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #19, bug#64806 (group make): When the stuff hangs, can you use ProcessExplorer to see which mutexes are actually used by these Make processes, and how many of them are used? You can find the code which manipulates the mutexes in src/w32/w32os.c (look for the osync_* functions ne

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #18, bug#64806 (group make): Very strange. Looks like the parent process is waiting for the child to finish, and the child process cannot acquire the mutex and also waits. Are all of the 8 sub-make's in the same situation? FWIW, I tried to run the Makefile you sent on my syste

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #16, bug#64806 (group make): >From the backtrace of the hung process, it looks like we wait forever for a mutex to be released, which means some child process that holds the mutex exited. But the mutex is never released. Do you see any other related sub-processes that are hung

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #13, bug#64806 (group make): It would be helpful to understand which code cause the "Error 130" message to be displayed, so as to allow interpreting that error, which might give us some hint about what's going on. If 130 is a value obtained from GetLastError, then its meaning so

[bug #64806] "invalid output sync mutex" on windows

Follow-up Comment #8, bug #64806 (project make): Is the brechtsanders build a 32-bit executable or a 64-bit executable? If it's a 64-bit executable, maybe the problem only rears its ugly head in a 64-bit build, because the ezwinports stuff is 32-bit. ___

[bug #64806] "invalid output sync mutex" on windows

Update of bug #64806 (project make): Triage Status:None => Need Info ___ Follow-up Comment #4: This bug report lacks a reproduction recipe, preferably one that doesn't require to download huge p

Re: GNU make troubleshooting

> From: Paul Smith > Cc: br...@clisp.org, bug-make@gnu.org > Date: Sun, 27 Aug 2023 09:16:59 -0400 > > On Sun, 2023-08-27 at 08:51 +0300, Eli Zaretskii wrote: > > This checklist is very useful, but to make it even more useful, it > > lacks two things: > > > &

Re: GNU make troubleshooting

> From: Paul Smith > Date: Sat, 26 Aug 2023 12:48:05 -0400 > > I added a new appendix to the GNU make manual for troubleshooting help; > I haven't pushed it yet. See below. Comments welcome. Thanks, this sounds very useful. Some comments below. >If you have problems with GNU Make, first

Re: GNU make troubleshooting

> From: Bruno Haible > Date: Mon, 10 Jul 2023 21:41:24 +0200 > > Paul Smith wrote: > > Showing the "macroexpanded make sources" is difficult because make > > doesn't just expand an entire line then parse it. Makefile syntax is > > context-sensitive so you can't know how or if to expand parts of

Re: GNU make troubleshooting

> From: Jeffrey Walton > Date: Mon, 10 Jul 2023 16:34:49 -0400 > Cc: bug-make@gnu.org > > I would add GNU's make lacks minimal debug facilities. I think "make -p" and "make -d" do provide ample debugging capabilities. > I think trace is worthless. It does not help the folks writing > makefiles.

[bug #64339] $(filter) and $(filter-out) interpret "match" in surprising ways

Triage Status: None ___ Follow-up Comments: --- Date: Thu 22 Jun 2023 10:07:13 PM IDT By: Eli Zaretskii The GNU Make Manual says: '$(filter-out PATTERN...,TEXT)' Return

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Sun, 18 Jun 2023 21:33:03 +0100 > Cc: bug-make@gnu.org > > Just checking to see if there is still interest in this feature. Nothing's changed, so yes.

Re: Unable to cross build for Windows

> From: Martin Dorey > CC: "bug-make@gnu.org" > Date: Fri, 9 Jun 2023 06:32:28 + > msip_labels: > > #include > > intptr_t _get_osfhandle(int); > typedef void* HANDLE; > > HANDLE fn() { >   return (HANDLE)_get_osfhandle(0); > } > martind@sirius:~/tmp/svensson-2023-06-08$ gcc -c -Wbad-funct

Re: Unable to cross build for Windows

> Date: Thu, 8 Jun 2023 20:39:43 +0200 > CC: > From: Torbjorn SVENSSON > > > If you get the error about casting _get_osfhandle to HANDLE only for > > the 32-bit build, and you don't care about that build, then just > > ignore it. But if that error is emitted for the 64-bit build, then > > there

Re: Unable to cross build for Windows

> Date: Thu, 8 Jun 2023 16:19:04 +0200 > CC: > From: Torbjorn SVENSSON > > On 2023-06-08 16:14, Eli Zaretskii wrote: > >> Date: Thu, 8 Jun 2023 14:44:35 +0200 > >> From: Torbjorn SVENSSON > >> > >> /build/gnu-make_4.4.1-45-g07fcee35/sr

Re: Unable to cross build for Windows

> Date: Thu, 8 Jun 2023 14:44:35 +0200 > From: Torbjorn SVENSSON > > /build/gnu-make_4.4.1-45-g07fcee35/src/function.c: In function > 'windows32_openpipe': > /build/gnu-make_4.4.1-45-g07fcee35/src/function.c:1676:12: error: cast from > function call of type 'intptr_t {aka long long int}' to non

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Wed, 17 May 2023 18:04:55 -0400 > > To remind: the purpose of these is to provide a makefile-based way to > _develop_ GNU Make itself, on platforms where we can't run ./configure > to get an automake-generated makefile. > > If you need to build G

Re: New feature request: custom Makefile location

> Date: Fri, 5 May 2023 12:47:35 +0300 > From: Nagy Ákos > > I want to configure a custom location for a Makefile. > > I use the make tool as sysadmin, and I use the same makefile for each > usualy docker project, and I need to copy it to all folders where I use > it, and I need to update it o

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 30 Apr 2023 09:55:55 -0400 > > On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote: > > I agree with the list.  As for Basic.mk, we can forget about it from > > my POV.  Paul should make the call, bu

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Tue, 11 Apr 2023 14:50:53 +0100 > Cc: bug-make@gnu.org, psm...@gnu.org > > > AFAIK, GetACP can never return UTF-8, except if the program was > > compiled with those resources. > > In the scenario I am describing, Make was compiled with the resource, > so GetACP sho

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Tue, 11 Apr 2023 14:42:30 +0100 > Cc: bug-make@gnu.org, Paul Smith > >> I don't think this is needed: if GetACP returns the UTF-8 codepage, it >> must be that UTF-8 is supported. I'm not aware of any way of >> affecting GetACP other than by a manifest such as this

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Tue, 11 Apr 2023 12:01:20 +0100 > Cc: Eli Zaretskii , bug-make@gnu.org > > > Being able to know whether UTF-8 is supported or not is a valid > > concern. How about adding this information to what "make --version" > > shows

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Thu, 6 Apr 2023 22:04:48 +0300 > Cc: bug-make@gnu.org, Paul Smith > > Hi and sorry to bother you again. > > I haven't received any response so > I was wondering if there is still > interest in doing this. It's on my todo, but I'm busy these days. Also, I'm still

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Mon, 27 Mar 2023 23:04:52 +0100 > Cc: bug-make@gnu.org > > > Should we fail here? Or should we build without UTF-8 support since we > > don't have a resource compiler? I think that's what the configure > > version does, right? > > You are right, that was an incon

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 27 Mar 2023 16:35:42 -0400 > > +:FindWindres > +:: Show the resource compiler version that we found > +echo. > +call %RC% --version > +if not ERRORLEVEL 1 goto Build > +echo No %RC% found. > +exit 1 > > Should we fail here? Or should we bui

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Sat, 25 Mar 2023 13:19:00 + > Cc: psm...@gnu.org, bug-make@gnu.org > > > Also, I'd name the files slightly differently, something like > > w32-utf8.*, to make their relation to Windows more evident. > > Note that in the patch, these files are put under the w32

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Tue, 21 Mar 2023 15:08:52 + > Cc: bug-make@gnu.org, Paul Smith > > > You can submit diffs against the last released version here as well. > > In that case, I am simply re-attaching the patch I originally sent in > this thread, because that was already develope

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Tue, 21 Mar 2023 12:52:54 + > Cc: bug-make@gnu.org, Paul Smith > > > If so, could you please post it again, rebased on the current Git > > master? > > There is an issue here:I noticed that when I was trying to build > (cross-compile) Make for Windows using

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Mon, 20 Mar 2023 21:47:27 + > Cc: bug-make@gnu.org, Paul Smith > > Any thoughts for next steps then? If the patch ready to be installed? If so, could you please post it again, rebased on the current Git master? And would you please consider working on changi

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Mon, 20 Mar 2023 14:58:39 + > Cc: bug-make@gnu.org, Paul Smith > > Still my concern would be: assuming that we actually learn something > from this test, how would we know: > > 1) Which other functions besides stricmp are affected?Maybe > letter-case is no

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Mon, 20 Mar 2023 13:45:14 + > Cc: bug-make@gnu.org, Paul Smith > > > That's most probably because $(wildcard) calls a Win32 API that is > > case-insensitive. So the jury is still out on this matter, and I > > still believe that the below is true: > > In that

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Sun, 19 Mar 2023 21:25:30 + > Cc: bug-make@gnu.org, Paul Smith > > I create a file src.β first: > > touch src.β > > and then run the following UTF-8 encoded Makefile: > > hello : > @gcc ©\src.c -o ©\src.exe > > ifneq ("$(wildcard src.β)","") > @echo src.β e

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Sun, 19 Mar 2023 16:34:54 + > Cc: bug-make@gnu.org, psm...@gnu.org > > > OK, but how is the make.exe you produced built? > > I actually did what you suggested but was somewhat confused with the > result.Usually I do this with 'ldd', but both msvcrt.dll and

Re: [PATCH] Use UTF-8 active code page for Windows host.

> Date: Sun, 19 Mar 2023 16:38:08 +0200 > From: Eli Zaretskii > Cc: bug-make@gnu.org > > > From: Costas Argyris > > Date: Sun, 19 Mar 2023 13:42:52 + > > Cc: bug-make@gnu.org > > > > Also, since the above experiments seem to suggest that we are

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Paul Smith > Date: Sun, 19 Mar 2023 10:32:36 -0400 > > It would be nice if there was a regression test or two created that > would show this behavior. If we add tests for this feature (and I agree it's desirable), we should generate the files with non-ASCII names for those tests as part

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 19 Mar 2023 10:27:16 -0400 > > Other people (like Eli who is the primary maintainer of GNU Make for > Windows) have other environments and do more vigorous testing. But I > don't believe Eli uses autotools on Windows, either. I do use autot

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Sun, 19 Mar 2023 13:42:52 + > Cc: bug-make@gnu.org > > Does this support require Make to be linked against the UCRT > run-time library, or does it also work with the older MSVCRT? > > I haven't found anything explicitly mentioned about this in the official > do

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Costas Argyris > Date: Sat, 18 Mar 2023 16:37:20 + > > This is a proposed patch to enable UTF-8 support in GNU Make running on > Windows host. Thanks. > Today, the make process on Windows is using the legacy system code page > because of the "A" functions > called in the source co

Re: GNU Make 4.4.0.91 on Cygwin

> From: Paul Smith > Cc: br...@clisp.org, bug-make@gnu.org > Date: Mon, 20 Feb 2023 10:36:07 -0500 > > Of course "testing on Windows" can mean many different things as there > are so many possible environments "on Windows". I only run one Windows > environment: (a) Windows 10/11 in a VM, (b) usi

Re: GNU Make 4.4.0.91 on Cygwin

> From: Paul Smith > Date: Sun, 19 Feb 2023 14:59:35 -0500 > > On Sun, 2023-02-19 at 20:32 +0100, Bruno Haible wrote: > > All "Device or resource busy" failures are gone. Only the 1 failure > > in category 'misc/general4' is still present. > > Hm. This is a test of this: > https://savannah.gnu.

Re: [PATCH] Check .exe as well when a target does not exist on OS/2

> Date: Sun, 15 Jan 2023 00:57:56 +0900 > From: KO Myung-Hun > CC: bug-make@gnu.org > > > How do you mean "make of mingw does not require $(EXEEXT)"? AFAICT, > > if the Makefile defines a target FOO, and there's a file FOO.exe that > > is up to date wrt its dependencies, the MinGW Make will reco

Re: [PATCH] Check .exe as well when a target does not exist on OS/2

> Date: Sat, 14 Jan 2023 23:40:57 +0900 > From: KO Myung-Hun > CC: bug-make@gnu.org > > > Please describe the use case in detail. This situation exists on > > other platforms, not just of OS/2, and we don't do anything like that > > for those other targets, AFAIK. Instead, the Makefile should u

Re: [PATCH] Check .exe as well when a target does not exist on OS/2

> From: KO Myung-Hun > Date: Fri, 13 Jan 2023 22:27:43 +0900 > > For example, > > foo: foo.c > gcc $@ $< > > This pattern is usually used on UNIX. However, on OS/2, gcc creates > foo.exe not foo when an extension is not present, and Make check foo > only. Therefore Make tries to build foo w

[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

Follow-up Comment #2, bug #63650 (project make): ??? Do you mean to say that commit f51fc130 caused this regression? If so, I don't understand: that commit changed code that is only used on MS-Windows, whereas the OP is on Arch Linux... _

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #15, bug #63638 (project make): Not sure I understand the problem. "make ... SHELL=cmd.exe" should do the trick. ___ Reply to this item at:

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Update of bug #63638 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #9, bug #63638 (project make): OK, then it should be easy for you to build Make by yourself. First, download the Make sources from here: https://ftp.gnu.org/gnu/make/make-4.4.tar.gz Unpack it (you will need tar.exe or bsdtar.exe). This will create a directory make-4.4 with

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #7, bug #63638 (project make): Where did you download the Make binaries? Do you have a MinGW development environment installed (GCC, Binutils, header files) that allow you to compile C programs? ___ Reply to this item a

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #3, bug #63638 (project make): It is a subtle feature of the native Windows port of GNU Make that it attempts to support PATH variables delimited by colons and semi-colons alike. It does that by converting colon delimiters to semi-colons. Which is a bit tricky, given the drive

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #5, bug #63638 (project make): (AFAIK, printf debugging is the only way in this case, since GDB on MS-Windows cannot follow-exec, and we are re-exec-ing ourselves. My only advantage was that I knew up from where to put the printf...) I didn't know about the CSTRLEN macro. I wi

[bug #16788] 'ORDINARY_MTIME_MAX' macro causes integral constant overflow

Follow-up Comment #4, bug #16788 (project make): With what compiler? The original warning seems to be from MSVC or maybe something else, but not from GCC. ___ Reply to this item at: _

Re: [PATCH] Bad sed expression in bootstrap.bat

> From: Paul Smith > Cc: gzaf...@gmail.com, bug-make@gnu.org > Date: Mon, 26 Dec 2022 09:15:56 -0500 > > On Mon, 2022-12-26 at 05:29 +0200, Eli Zaretskii wrote: > > How about reading the Sed script from a file, with the -f command- > > line argument? > > That w

Re: [PATCH] Bad sed expression in bootstrap.bat

> From: Paul Smith > Cc: gzaf...@gmail.com, bug-make@gnu.org > Date: Sun, 25 Dec 2022 21:02:25 -0500 > > On Sun, 2022-12-25 at 19:20 +0200, Eli Zaretskii wrote: > > So this command will work differently depending on which version of > > Windows it runs, and therefore

Re: [PATCH] Bad sed expression in bootstrap.bat

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 25 Dec 2022 09:06:53 -0500 > > On Sun, 2022-12-25 at 02:29 +0100, Giangiacomo Zaffini wrote: > > I cannot see where > > sed -e "s/$/ \\/" > > can be wrong on Windows command line or Windows PowerShell. > > It's because, apparently, cmd.exe s

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #8, bug #63516 (project make): The file name "d:foo" means on Windows "the file 'foo' in the directory that is current on drive 'd'. Yes, windows programs can have a separate current directory on each drive. You can see that if you do the following dance: C:\> cd foobar C:

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #5, bug #63516 (project make): Thanks for the patch. I have three comments: (1) The test under "WINDOWS32" should allow a backslash after the colon as well as a forward slash. (2) Do we want Make to consider "drive-relative" file names, as in "d:foo/bar", relative or absolute?

Re: Old timestamps in the future?

> From: Gisle Vanem > Date: Fri, 9 Dec 2022 15:38:08 +0100 > > Paul Smith wrote: > > > ... facilities that you don't specify (Cygwin? MinGW? WSL?) > > I'm using Cygwin as my POSIX toolbox. > > > But, note that touch writes timestamps in the current timezone by > > default. It could be that

Re: [PATCH] Bad timestamps on MinGW32

> From: Orgad Shaneh > Date: Thu, 3 Nov 2022 08:29:53 +0200 > Cc: bug-make@gnu.org > > > > Do you mean that __MINGW_USE_VC2005_COMPAT has no effect on this > > > platform? > > > > Indeed, it doesn't currently. But I wouldn't count on that, some > > future version could introduce it. > > Is ming

Re: [PATCH] Bad timestamps on MinGW32

> From: Jeffrey Walton > Date: Wed, 2 Nov 2022 16:22:51 -0400 > Cc: bug-make@gnu.org > > You might also be interested in __MINGW64__. That's possible, but AFAIK it is only defined after including some headers; the compiler itself doesn't define it. Caveat emptor. > I don't think it's a good id

Re: [PATCH] Bad timestamps on MinGW32

> 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. > > > > Thanks, but this cannot be done for all MinGW builds. There'

Re: [PATCH] Bad timestamps on MinGW32

> From: Orgad Shaneh > Date: Wed, 2 Nov 2022 18:32:49 +0200 > > 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

Re: GNU make 4.3.92 on mingw

> From: Paul Smith > Cc: br...@clisp.org, bug-make@gnu.org > Date: Tue, 25 Oct 2022 14:10:25 -0400 > > On Tue, 2022-10-25 at 19:37 +0300, Eli Zaretskii wrote: > > > A lot of these seem to be CRLF errors in the diff, where it would > > > otherwise match.  I know

Re: GNU make 4.3.92 on mingw

> From: Paul Smith > Date: Tue, 25 Oct 2022 12:07:08 -0400 > > On Tue, 2022-10-25 at 16:29 +0200, Bruno Haible wrote: > > With GNU make 4.3.92, this is down to 75 test failures. > > Just curious how this MinGW test works; are you running the MinGW > "cross-compiler" installed by the Cygwin packa

Re: GNU Make 4.3.92 release candidate available

> From: Paul Smith > Date: Mon, 24 Oct 2022 02:59:18 -0400 > > I expect this to be the final release candidate before GNU Make 4.4. > I will probably allow for testing for about a week. > > > GNU make is a tool which co

Re: GNU make 4.3.91 on mingw

> From: Bruno Haible > Date: Wed, 19 Oct 2022 03:06:51 +0200 > > On mingw (on Windows 10 in a Cygwin dev environment), compilation works > fine, but there are 91 test failures. FTR: I get only 2 failures in options/dash-q (and for a reason that is a non-issue: temporary batch files are not remov

[bug #63219] Introduce a close function for loadable plugins.

Follow-up Comment #3, bug #63219 (project make): If we are going to extend the API of the loadable modules, I think we will have to introduce API versions, because the new API will be binary-incompatible with the old one, and Make should refuse to load modules that are incompatible with the API fo

Re: [PATCH] Fix some temp file issues

> Date: Sat, 8 Oct 2022 21:23:53 -0700 > Cc: bug-make@gnu.org > From: Paul Eggert > > On 2022-10-08 21:19, Eli Zaretskii wrote: > > I meant the "b" part, not the "+" part. On systems where that changes > > the bytestream written to the file, the c

Re: [PATCH] Fix some temp file issues

> Date: Sat, 8 Oct 2022 15:22:50 -0700 > Cc: bug-make@gnu.org > From: Paul Eggert > > On 2022-10-08 00:14, Eli Zaretskii wrote: > >> tmpfile uses "wb+" (POSIX requires this) and we should be consistent in > >> all the paths that create temporary FIL

Re: [PATCH] Fix some temp file issues

> Date: Fri, 7 Oct 2022 21:37:24 -0700 > Cc: bug-make@gnu.org > From: Paul Eggert > > > I'd appreciate a more high-level description of the idea of the > > change, in addition to the gory details. > > I gave it a shot in the attached patch, which is an improved version of > the previous patch.

Re: [PATCH] Fix some temp file issues

> From: Paul Eggert > Cc: Paul Eggert > Date: Fri, 7 Oct 2022 00:02:25 -0700 > > This patch was prompted by a linker warning "warning: the use of > `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'" on > Fedora 36. It also fixes a few unlikely bugs and simplifies the > code in a couple

[bug #63157] Unlink temporary files.

Follow-up Comment #12, bug #63157 (project make): Thanks, the diffs look good (although I didn't actually test them). ___ Reply to this item at: ___ Me

[bug #63157] Unlink temporary files.

Follow-up Comment #10, bug #63157 (project make): If temp_stdin is fclosed, then there's no need to call close on its fileno. I don't think I follow your reasoning. Could you tell more details, including pointers to the source code? What do you mean by "We won't be able to use fclose, which is

[bug #63157] Unlink temporary files.

Follow-up Comment #6, bug #63157 (project make): > If the file is opened at the time of unlink, only file's name is removed from the directory and the file itself stays. When make exits the last reference to the file is gone and the file is deleted. That's what happens on Unix. On Windows, the u

[bug #63157] Unlink temporary files.

Follow-up Comment #4, bug #63157 (project make): This should be tested on MS-Windows. A file can only be deleted on MS-Windows if it isn't open by any program, and the patch (AFAICT) doesn't make sure the files are closed before unlinking them. I'm especially worried about the temp_stdin_unlink

  1   2   3   4   5   6   7   8   9   >