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

[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

[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. ___

[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

[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

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

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

[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

[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

[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

[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

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 >

[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)' Returns all whit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.β

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

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 >

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

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)

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

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

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

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

[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

[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

[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

[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

[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

[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

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

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

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's &g

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

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

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

[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

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: ___

[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

[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

Re: [PATCH] Port to 32-bit long + 64-bit time_t

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 03 Oct 2022 16:14:01 -0400 > > I needed another set of changes, since intmax_t is a new type and is > not available on Windows so we needed to add it to configure.ac etc. By "not available on Windows" you mean in MSVC, right? Because MinGW

Re: [PATCH] Port to 32-bit long + 64-bit time_t

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 02 Oct 2022 17:23:46 -0400 > > On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote: > > (This would not be needed if 'make' used Gnulib's inttypes module.) > > I would be happy to use it, if using it didn't import a ton of other > things

Re: Deprecating OS support

> From: Paul Smith > Cc: bug-make@gnu.org, Juan Manuel Guerrero > Date: Sat, 01 Oct 2022 14:48:01 -0400 > > On Sat, 2022-10-01 at 20:42 +0300, Eli Zaretskii wrote: > > The DJGPP project has been routinely porting all versions of Make up > > to and including 4.3. >

Re: Deprecating OS support

> From: Paul Smith > Date: Sat, 01 Oct 2022 13:02:55 -0400 > > With the upcoming release (4.4) I intend to announce that I'll be > removing support for the following platforms in the next, post-4.4 > release: > > - OS/2 (EMX) > - Amiga > - Native MS-DOS > > For the first two, I suspect

Re: GNU make 4.3.90 release candidate available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 26 Sep 2022 15:14:37 -0400 > > > Some binaries from Git for Windows are MinGW binaries, but some are > > MSYS2 binaries.  All those for which Git Bash says they are in /bin > > (as opposed to /mingw64/bin) are MSYS2 binaries, they depend on

Re: GNU make 4.3.90 release candidate available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 26 Sep 2022 14:23:40 -0400 > > On Mon, 2022-09-26 at 20:23 +0300, Eli Zaretskii wrote: > > The following tests should be disabled on MS-Windows, because they > > cannot possibly work: > > I have

Re: GNU make 4.3.90 release candidate available

> From: Paul Smith > Cc: coordina...@translationproject.org > Date: Tue, 20 Sep 2022 14:36:05 -0400 > > A new release candidate for GNU make 4.4 is available now for download: > > 0c3daaec8c81bf72f460677ccda32364 make-4.3.90.tar.lz > 54726144a7ae0465451f8ca0740f3d1f make-4.3.90.tar.gz

Re: GNU make 4.3.90 release candidate available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 26 Sep 2022 12:31:34 -0400 > > On Mon, 2022-09-26 at 12:16 -0400, David Boyce wrote: > > BTW wget complains about the certificate: > > > > $ wget https://alpha.gnu.org/gnu/make/make-4.3.90.tar.gz > > --2022-09-26 09:12:58--  

Re: GNU make 4.3.90 release candidate available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 25 Sep 2022 08:28:50 -0400 > > On Sun, 2022-09-25 at 13:30 +0300, Eli Zaretskii wrote: > > > From: Paul Smith > > > Cc: bug-make@gnu.org > > > Date: Sat, 24 Sep 2022 16:44:44 -0400 > > >

Re: GNU make 4.3.90 release candidate available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sat, 24 Sep 2022 16:44:44 -0400 > > On Sat, 2022-09-24 at 16:41 -0400, Paul Smith wrote: > > makeint.h already has HAVE_MAKEINT_H > > Doh, I meant HAVE_INTTYPES_H of course. Is the below OK? --- src/makeint.h~0 2022-09-18

Re: GNU make 4.3.90 release candidate available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sat, 24 Sep 2022 13:10:00 -0400 > > > Here are the proposed patches for the above 2 warnings.  Paul, if you > > agree with them, I will install them in the repository. > > These changes look good to me, thanks! Thanks, installed.

Re: GNU make 4.3.90 release candidate available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sat, 24 Sep 2022 13:45:57 -0400 > > On Wed, 2022-09-21 at 06:18 +0100, Sam James wrote: > > Can I suggest forwarding to the platform-testers@ mailing list as > > well? > > I've never heard of this; is it @gnu.org? Yes, platform-test...@gnu.org.

Re: GNU make 4.3.90 release candidate available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sat, 24 Sep 2022 13:42:39 -0400 > > On Sat, 2022-09-24 at 14:17 +0300, Eli Zaretskii wrote: > > Here are the proposed patches: > > > > --- src/function.c~02022-09-18 22:06:17.0 +0300 > > +

Re: GNU make 4.3.90 release candidate available

I've built this with mingw.org's MinGW for native MS-Windows. I found several issues during the build, some of them specific to Windows, others more general. Below are the build-time issues that are specific to MS-Windows, and the proposed patches. Paul, I'll wait for your okay before

Re: GNU make 4.3.90 release candidate available

I've built this with mingw.org's MinGW for native MS-Windows. I found several issues during the build, some of them specific to Windows, others more general. (I didn't yet run the test suite, I intend to do that next.) Here are the build-time issues that aren't specific to MS-Windows:

Re: [PATCH] Port to 32-bit long + 64-bit time_t

> Date: Thu, 22 Sep 2022 11:00:52 -0700 > Cc: rsbec...@nexbridge.com, bug-make@gnu.org > From: Paul Eggert > > On 9/21/22 23:49, Eli Zaretskii wrote: > > This will cause problems in the native MS-Windows builds, where printf > > in the system C runtime doesn't support

  1   2   3   4   5   6   7   8   >