"*** INTERNAL: readdir: Invalid argument" error

For the actual use case, see the discussion on the MinGW mailing list about that. The important part starts here: https://sourceforge.net/mailarchive/message.php?msg_id=30846737 To make the long story short: . The problem is a complete failure of Make to run, where it bails out before e

Re: "*** INTERNAL: readdir: Invalid argument" error

> Date: Wed, 15 May 2013 07:44:25 -0700 > From: David Boyce > Cc: Eli Zaretskii , bug-make > > Given that this is a Windows-specific problem, couldn't the fallback > be that make switches over to native calls (FindXXXFile or > QueryDirectory or whatever) to read th

Re: "*** INTERNAL: readdir: Invalid argument" error

> Date: Wed, 15 May 2013 08:07:55 -0700 > From: David Boyce > Cc: Paul Smith , bug-make > > On Wed, May 15, 2013 at 7:54 AM, Eli Zaretskii wrote: > > > because of the need to convert the file names from UTF-16 to > > something the rest of the code can gr

Re: "*** INTERNAL: readdir: Invalid argument" error

> Date: Wed, 15 May 2013 11:35:47 -0700 > From: David Boyce > Cc: bug-make > > 2. What to do about the more general case of an opendir/readdir > failure, when making legitimate use of the caching function, is still > undetermined. Is it better to fail, as now, but with a somewhat better > error

Re: GNU make release candidate 3.99.90 available

> From: Paul Smith > Date: Fri, 17 May 2013 04:12:15 -0400 > > Hi all. The first release candidate for the next release of GNU make, > GNU make 4.0, is now available for download: > > http://alpha.gnu.org/gnu/make/make-3.99.90.tar.gz > 37c2d65196a233a8166d323f5173cdee > http://alpha.gnu.org/g

[bug #30714] List of shell commands is outdated/Fallback to shell

Update of bug #30714 (project make): Status:None => Fixed Open/Closed:Open => Closed Component Version:3.81 => SCM Fixed Release:

Re: GNU make release candidate 3.99.90 available

> From: Paul Smith > Date: Fri, 17 May 2013 04:12:15 -0400 > > Hi all. The first release candidate for the next release of GNU make, > GNU make 4.0, is now available for download: Paul, can you please add 4.0 to the list of versions accepted by the Savannah bug tracking UI, so that bugs fixed b

Re: GNU make release candidate 3.99.90 available

> Date: Sat, 18 May 2013 14:00:44 -0400 > From: Boris Kolpackov > Cc: bug-make@gnu.org > > I've also tested the up-to-date check time compared to 3.81 > and the new version is significantly faster (5.63s vs 8.15s). Can you show a Makefile to test that? I'd like to measure this on Windows. Than

Re: GNU make release candidate 3.99.90 available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 20 May 2013 09:24:40 -0400 > > On Fri, 2013-05-17 at 22:35 +0300, Eli Zaretskii wrote: > > When a dynamic extension is being remade, it is unloaded by calling > > unload_file. The latter looks up its argument in

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

> Date: Mon, 27 May 2013 00:42:34 +0200 > From: Frank Heckenbach > Cc: bug-make@gnu.org > > One issue, though it might seem strange that I'm the one to mention > it, is that it might be POSIX specific. How do other systems behave, > can they set O_APPEND via fcntl or otherwise This can be done o

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

> From: Paul Smith > Cc: Frank Heckenbach , stefano.lattar...@gmail.com, > bug-make@gnu.org > Date: Mon, 27 May 2013 14:09:42 -0400 > > The original issue reported is that if you do something like this: > > make -j >make.out > > and your make environment is recursive so you invoke one or

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

> Date: Wed, 29 May 2013 09:32:55 +0200 > Cc: stefano.lattar...@gmail.com, bug-make@gnu.org > From: Frank Heckenbach > > Eli Zaretskii wrote: > > > > Date: Mon, 27 May 2013 00:42:34 +0200 > > > From: Frank Heckenbach > > > Cc: bug-make@gnu.org

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

> Date: Thu, 30 May 2013 04:18:22 +0200 > Cc: psm...@gnu.org, stefano.lattar...@gmail.com, bug-make@gnu.org > From: Frank Heckenbach > > > . get the handle that corresponds to (e.g.) stdout > > > > . produce a new descriptor for that handle with O_APPEND flag > > > > . use dup2 to replace

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

> Date: Fri, 31 May 2013 05:36:24 +0200 > Cc: psm...@gnu.org, stefano.lattar...@gmail.com, bug-make@gnu.org > From: Frank Heckenbach > > Eli Zaretskii wrote: > > > > From: Frank Heckenbach > > > > > > However, there may still be a problem. The tri

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

> Date: Fri, 31 May 2013 16:58:21 +0200 > Cc: psm...@gnu.org, stefano.lattar...@gmail.com, bug-make@gnu.org > From: Frank Heckenbach > > > > void write (int fd, void *data, size_t size) > > > { > > > if (getflags (fd) & O_APPEND) > > > { > > > lock_mutex (get_mutex (fd)); > > >

Re: make doesn't recognise DOS internal commands CD, MOVE etc.

> From: Steve Taylor > Date: Thu, 6 Jun 2013 22:04:59 + > > Is there a fix for this? > > I'm using GNU Make 3.81 on Windows 7. > > Lines like this... > > CD D:\Steve\data > MOVE prog1.log .. > > ... cause an error like this... > process_begin: CreateProcess(NULL, CD D:\Steve

Re: [PATCH 2/2] Do not use DOS paths on Cygwin

> From: Pavel Fedin > Date: Tue, 30 Jul 2013 14:44:58 +0400 > > Currently make's configure suggests that it should use DOS-style paths on > Cygwin. This is not true, and this assumption makes path-related mechanisms > to work incorrectly. Currently Cygwin package supplies manual hint in > config

Re: [PATCH1/2] Use spawn() on Cygwin

> From: Pavel Fedin > Date: Tue, 30 Jul 2013 14:42:23 +0400 > > Please take this patch, Cygwin team told that they would like to integrate > with upstream. I have already posted it some time ago but got no reply. > The patch significantly improves performance of Make under Cygwin. Thanks. Is

Re: [PATCH1/2] Use spawn() on Cygwin

> Cc: bug-make@gnu.org, Pavel Fedin > From: Roland Schwingel > Date: Tue, 30 Jul 2013 18:12:55 +0200 > > I am using Pavels patch for some months now in my private version of > gnumake on cygwin heavily and I could not find any regression with it up > to now and gnumake is in my use cases clear

Re: [PATCH 2/2] Do not use DOS paths on Cygwin

> Cc: bug-make@gnu.org, Pavel Fedin > From: Roland Schwingel > Date: Tue, 30 Jul 2013 18:29:07 +0200 > > I clearly think the DOS paths mode should remain in even for cygwin. I > know that there are objections in cygwins top level management against > this. When this feature was introduced for

Re: [PATCH1/2] Use spawn() on Cygwin

> Date: Tue, 30 Jul 2013 11:52:58 -0500 > From: Norbert Thiebaud > Cc: Pavel Fedin , bug-make@gnu.org > > fork() is a very expensive operation in cygwin. Yes, I know. But without it, some things that are expected of a Posix behavior will not work. A notable example is that the child process in

Re: [PATCH 2/2] Do not use DOS paths on Cygwin

> Date: Wed, 31 Jul 2013 01:31:56 +0400 > From: Pavel Fedin > Cc: bug-make@gnu.org > > The actual problem with this is that Make supports either DOS or POSIX > style paths, but not simultaneously. That's not true, at least that's not how things are designed to work. Please show a small self-con

Re: [PATCH1/2] Use spawn() on Cygwin

> Date: Wed, 31 Jul 2013 01:24:45 +0400 > From: Pavel Fedin > Cc: bug-make@gnu.org > > There was a short discussion in Cygwin ML with test results, sorry, i > cannot find the URL, Google fails to find it. Can you at least tell when (year and month) this discussion took place? In any case, I th

Re: [PATCH1/2] Use spawn() on Cygwin

> Date: Fri, 2 Aug 2013 22:49:31 -0400 > From: Christopher Faylor > > On Tue, Jul 30, 2013 at 08:02:54PM +0300, Eli Zaretskii wrote: > >> Date: Tue, 30 Jul 2013 11:52:58 -0500 > >> From: Norbert Thiebaud > >> Cc: Pavel Fedin , bug-make@gnu.org > >&g

Re: [PATCH 2/2] Do not use DOS paths on Cygwin

> From: Pavel Fedin > Date: Mon, 05 Aug 2013 09:19:18 +0400 > > IMHO it's a little bit inconvenient that you have to use config.cache trick > in order to build a fully working Make for Cygwin, and this is not > documented anywhere. First time, when i didn't know about this, i've got a > problem.

Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated

> Date: Mon, 5 Aug 2013 21:34:31 +0400 > From: Pavel Fedin > > fork()-based code temporary sets 'environ' variable to child's environment, > which appears to contain current directory. EMX code didn't do that. > The problem gets triggered only if you try to call something which is not in > yo

Re: [PATCH 2/2] Do not use DOS paths on Cygwin

> Date: Mon, 5 Aug 2013 22:04:44 +0400 > From: Pavel Fedin > CC: m...@cgf.cx, bug-make@gnu.org > > > I don't yet understand why you have a problem in the first place. It > > sounds like the single issue is with the 'abspath' function, is that > > correct? > > Yes, correct. In that case, we ne

Re: [PATCH 2/2] Do not use DOS paths on Cygwin

> From: Pavel Fedin > Cc: m...@cgf.cx, bug-make@gnu.org > Date: Tue, 06 Aug 2013 15:05:51 +0400 > > > In that case, we need to fix 'abspath', not disable this feature. > > Ok. If you don't mind, i can try new approach on this. Will it be OK ? Yes, please. _

Re: [PATCH 2/2] Do not use DOS paths on Cygwin

> From: Pavel Fedin > Cc: m...@cgf.cx, bug-make@gnu.org > Date: Tue, 06 Aug 2013 17:46:14 +0400 > > 1. abspath on Cygwin returns UNIX-style paths and on pure DOS/Windows - > DOS-style. This is what I'd expect. > If DOS-style absolute path is already supplied, it will leave it as > is. Again, t

Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated

> From: Pavel Fedin > Cc: bug-make@gnu.org > Date: Tue, 06 Aug 2013 10:46:51 +0400 > > Runtime ??? I am sorry, but what's the sense ? I tried to explain that in my first response: 'fork' has a certain semantics and implements requirements that 'spawn' does not. Since Cygwin is a Posix environm

Re: [PATCH 2/2] Do not use DOS paths on Cygwin

> From: Pavel Fedin > Cc: m...@cgf.cx, bug-make@gnu.org > Date: Wed, 07 Aug 2013 10:22:31 +0400 > > > > 2. PATH_SEPARATOR on Cygwin is ':' and on pure DOS/Windows is ';'. > > > > This is true, but how is this relevant to the issue at hand? > > 'abspath' does not deal with PATH-style directory li

Re: bug about

> Date: Thu, 8 Aug 2013 15:49:02 +0800 (CST) > From: 丁雍 > > hello, i come accross a problem, which i can't finger out, can you help me? > It's detail like this: Sorry, but what is the bug? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu

Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated

> From: Paul Smith > Date: Fri, 16 Aug 2013 14:18:31 -0400 > Cc: bug-make@gnu.org > > > >So, the question is very simple: is it technically possible to ensure > > >that the operations make takes today in the child between fork and exec > > >can be handled properly in a spawn-based implementation?

Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated

> Date: Fri, 16 Aug 2013 22:52:55 +0400 > From: Pavel Fedin > Cc: Christopher Faylor , > bug-make@gnu.org > > To me current situation looks non-constructive. You say: "Current > implementation works, new implementation theoretically may fail > (because it's new), so we

[bug #39825] bad redirection with >

Follow-up Comment #1, bug #39825 (project make): I'm sorry, but what does objdump have to do with Make? Is there any problem with Make? If so, please describe it. ___ Reply to this item at: _

[bug #39825] bad redirection with >

Follow-up Comment #3, bug #39825 (project make): Yes, it's clear now, thanks. However, I cannot reproduce this problem on my machine, neither with Make 3.80 nor with 3.81. Redirection or not, objdump works fine for me here. Is the problem specific to objdump, or does any program fail when redir

Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated

> From: Pavel Fedin > Date: Thu, 22 Aug 2013 09:43:09 +0400 > Cc: bug-make@gnu.org > > What if we implement posix_spawn() for Cygwin ? Would you like > that ? If Paul accepts that for platforms other than Cygwin, I certainly won't mind. But please wait for Paul and Christopher to provide their

[bug #39825] bad redirection with >

Follow-up Comment #5, bug #39825 (project make): I can explain why sh.exe makes the difference. GNU Make on Windows always prefers a Unixy shell if it can find it. If it cannot find it, it uses cmd.exe. Also, Make does not invoke the shell if there are no shell features, such as quoting and red

[bug #39825] bad redirection with >

Update of bug #39825 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Reply to this item at:

Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated

> Date: Mon, 2 Sep 2013 10:32:38 -0400 > From: David Boyce > Cc: Christopher Faylor , bug-make > > All this arguing has been about the value of spawn as a speed enhancement: > > Pro: spawn is way faster! > Con: but it may destabilize things - we'll stick with slow-but-stable fork. > > Which ig

Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens

> Date: Thu, 5 Sep 2013 10:38:16 +0100 > From: Tim Murphy > Cc: Byron Hawkins , > Boris Kolpackov , bug-make > > It would be nice even if make was able to guess what might be > happening and issue a warning It already does: /usr/tmp/Gma07464:2: *** missing separator (did you mean TAB i

Suffix rules with dependencies

In this thread: http://lists.gnutls.org/pipermail/gnutls-devel/2013-September/006453.html and specifically in this message and its followups: http://lists.gnutls.org/pipermail/gnutls-devel/2013-September/006460.html there's evidence that GNU Make no longer treats suffix rules with prerequi

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> From: Paul Smith > Cc: e...@gnu.org, david.s.bo...@gmail.com, bug-make@gnu.org > Date: Thu, 12 Sep 2013 04:19:13 -0400 > > I've reworked the output methods for make a good bit. Hopefully the > code is somewhat simpler and more understandable. Sorry for the larger > changes, but it seemed nece

Re: Suffix rules with dependencies

> From: Paul Smith > Cc: l...@gnu.org, bug-make@gnu.org > Date: Mon, 16 Sep 2013 08:11:25 -0400 > > > there's evidence that GNU Make no longer treats suffix rules with > > prerequisites "as normal files with funny names", as described in the > > manual. > > > > Did the behavior indeed change, an

Re: GNU make 3.99.92 release candidate is available

> From: Paul Smith > Date: Mon, 23 Sep 2013 01:06:45 -0400 > > Hi all. The third release candidate, 3.99.92, for the next version of > GNU make is now available on alpha: > > ftp://alpha.gnu.org/gnu/make/make-3.99.92.tar.bz2 > 7ef9dabbfd8ad202ef05edb5836eb4b9 > ftp://alpha.gnu.org/gnu/make/ma

Re: GNU make 3.99.92 release candidate is available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 23 Sep 2013 11:48:40 -0400 > > On Mon, 2013-09-23 at 11:02 +0300, Eli Zaretskii wrote: > > There's also another problem: you added a test script dash-w, where we > > already had a dash-W. On Windows, th

Re: GNU make 3.99.92 release candidate is available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 23 Sep 2013 13:02:20 -0400 > > rm -rf test/scripts/options/dash-* > git pull > git reset --hard > > "git status" should now show no changes. Let me know if that doesn't > help. You should definitely not have any local changes before

Re: GNU make 3.99.92 release candidate is available

> From: Denis Excoffier > Date: Tue, 24 Sep 2013 06:53:43 +0200 > > Since the patch makes merely Cygwin as a copy of EMX, and that > same patch used (with very minor modifications) to work with > make-3.99.91, perhaps this suggests that the EMX platform is > broken under make-3.99.92. Could be,

Re: GNU make 3.99.92 release candidate is available

> From: Denis Excoffier > Date: Tue, 24 Sep 2013 12:34:35 +0200 > Cc: Eli Zaretskii , > pavel_fe...@mail.ru > > On 2013-09-24 07:40, Eli Zaretskii wrote: > > Could be, as I don't think I've seen any EMX-related changes for a > > long time. > On the

Re: GNU make 3.99.92 release candidate is available

> Date: Tue, 24 Sep 2013 08:15:15 -0700 > From: David Boyce > Cc: bug-...@denis-excoffier.org, bug-make > > Looks like there's a strong risk that no version of the spawn patch will > get into 4.0 which would be a shame IMHO. If someone submits a patch that enables spawn for Cygwin under a speci

Re: make check under Cygwin

> Date: Wed, 25 Sep 2013 11:30:14 +0200 > From: Denis Excoffier > > 4) If i do _not_ apply the following patch: > > % type patch > diff -uNr make-3.99.92-original/configure > make-3.99.92-patched/configure > --- make-3.99.92-original/configure 2013-09-23 06:50:50.0 +0159 > +++ make-3.

Re: make check under Cygwin

> From: Pavel Fedin > Cc: bug-make@gnu.org > Date: Wed, 25 Sep 2013 16:12:10 +0400 > > Just a reminder. I have followed your suggestion and fixed this a month > ago. Please try this: > http://lists.gnu.org/archive/html/bug-make/2013-08/msg00031.html I didn't forget, I just don't like the way yo

[bug #30323] No path in MAKE_COMMAND (with fix)

Update of bug #30323 (project make): Severity: 3 - Normal => 2 - Minor Item Group: Bug => Enhancement Status:None => Wont Fix Operating System:

Re: make check under Cygwin

> From: Pavel Fedin > Cc: bug-...@denis-excoffier.org, bug-make@gnu.org > Date: Thu, 26 Sep 2013 10:47:15 +0400 > > > There must be a better way, since the only difference between Posix and > Windows file > > names is the X: prefix of every absolute file name. > > Yes. But in certain cases (Cyg

Re: "load" on Windows

> From: "Gisle Vanem" > Date: Thu, 3 Oct 2013 22:03:14 +0200 > > VERSION = 3.99.93 > ifeq ($(MAKE_VERSION),$(VERSION)) > -load ./mk_test.dll > endif > > The above was needed since I needed to use mingw-make version 3.82.90 > to build this new make.exe. Windows doesn't allow make.exe to be linked

Re: "load" on Windows

> From: "Gisle Vanem" > Date: Thu, 3 Oct 2013 23:07:50 +0200 > > Since I do get "Loaded modules: mk_test.dll" it mean it's loaded okay. But > it's never run. So it must be some issue with how I use the extension. I > looked > at section 12.2.4 in the docs and cooked it from that. Well, the te

Re: "load" on Windows

> Date: Fri, 04 Oct 2013 09:46:10 +0300 > From: Eli Zaretskii > Cc: bug-make@gnu.org > > > From: "Gisle Vanem" > > Date: Thu, 3 Oct 2013 23:07:50 +0200 > > > > Since I do get "Loaded modules: mk_test.dll" it mean it's loaded okay. Bu

Re: "load" on Windows

> From: "Gisle Vanem" > Date: Sat, 5 Oct 2013 14:33:26 +0200 > > "Eli Zaretskii" wrote: > > > Well, the tests in the test suite that test this feature did work for > > me at some point, so you may wish first to verify they do for you, and > &

Re: "load" on Windows

> Date: Sat, 05 Oct 2013 16:34:11 +0300 > From: Eli Zaretskii > Cc: bug-make@gnu.org > > Paul, if this limitation is deliberate, I suggest to document it where > we explain the arguments of gmk_add_function. One other important thing that doesn't seem to be cover

Re: "load" on Windows

> Date: Sat, 5 Oct 2013 10:22:13 -0400 > From: David Boyce > Cc: Gisle Vanem , Paul Smith , bug-make > > > > [1:text/plain Hide] > > On Sat, Oct 5, 2013 at 9:34 AM, Eli Zaretskii wrote: > > > while (*e && ( (*e >= 'a' &

[bug #40225] Deterministic output ordering

Follow-up Comment #3, bug #40225 (project make): Just a nit: on MS-Windows, $wildcard always returns file names in sorted order, because that's how the underlying filesystem behaves. ___ Reply to this item at:

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #2, bug #40226 (project make): Could you please provide a minimal Makefile and a test case to reproduce the problem you saw? I'm sorry, but I have a difficulty understanding your description of the bug you found in the code; hopefully a test case will help me see the light. Tha

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #5, bug #40226 (project make): Paul: If you already see and understand the problem, by all means take it. I didn't yet have time to even build the release ;-). Thanks. ___ Reply to this item at:

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #7, bug #40226 (project make): Christian: Thanks for the extended explanations. For the record: I don't see this on my system, at least not with the simple recipe you provided. Moreover, the (second) call to `decode_switches`, after `prepare_mutex_handle_string`, never examines

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #8, bug #40226 (project make): Are we going to release 4.01 soon? If not, is the problem serious enough to fix it in the present code? Or can I safely use the Windows binary of 4.0 unaltered? (As I wrote, the problem does not happen in my usage.)

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #4, bug #40227 (project make): Please provide a minimal Makefile that can be used to reproduce the problem. Thanks. I also don't understand why you needed to define va_copy for MinGW. AFAICS, MinGW does have a proper definition for it (MSVC indeed doesn't, AFAIK). __

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #5, bug #40227 (project make): Moreover, MinGW does not provide _vsnprintf_s (or any of the *_s functions), so I don't see how did Make compile for you after the change. It fails for me. ___ Reply to this item at:

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #7, bug #40227 (project make): You are using MinGW64. I use MinGW32 from mingw.org, a different distribution with a different set of headers. The tests you propose on __MINGW32_MAJOR_VERSION etc. will not distinguish between MinGW64 and MinGW32. So we need some other preproces

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #14, bug #40227 (project make): Please show me the debugging session where you saw the problem, with all the details. I need to see that to make sure we understand the problem completely. Just see how many different hypotheses and suggestions were offered in this discussion, an

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #16, bug #40227 (project make): Thanks. My debugging shows that the problem does not happen with the MinGW32 build, because vsnprintf is replaced by a conforming implementation in libmingwex.a, which is linked in by default. (So I guess mingw.org's distribution is not as bad as

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #17, bug #40227 (project make): Sorry, wrong patch. Please use this one instead. (file #29381) ___ Additional Item Attachment: File name: vsnprintf2.dif Size:0 KB __

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #1, bug #40241 (project make): Can you show a Makefile recipe that fails in this way? Does it fail because /usr/bin/install is actually mapped to some directory like C:\MSYS\bin, and /usr/bin does not really exist in the filesystem? Or does it fail because you think CreateProce

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #19, bug #40227 (project make): I installed changes for all of the problems, with the single exception of the stack size for 64-bit builds. For the latter problem, I would like to see the details: how does the problem manifest itself, and why did you need such a large increase i

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #3, bug #40241 (project make): Thanks for the test case. I'm reluctant to "go slow" in this case, because that would change the semantics of the command, as it doesn't have any shell-specific features. Instead, could you please try the attached patch? (file #29405) __

Re: Make 4.0 does not compile with MSVC 7.1

> Date: Thu, 10 Oct 2013 17:42:11 +0200 > From: Bob Shark > > Contrary to the Statement in readme.w32 Make 4.0 does not comile with > MSVC7.1. It looks like no one who does have MSVC 7 installed (I don't) is tracking the release candidates. So, unfortunately, these problems are only detected wh

Re: Make 4.0 does not compile with MSVC 7.1

> Date: Sat, 19 Oct 2013 11:48:44 +0300 > From: Eli Zaretskii > Cc: bug-make@gnu.org > > > 1) _TRUNCATE is unknown > > Workaround: use (size_t)-1 > > 2) vsnprintf unknown > > Workaround: use _vsnprintf > > 3) _vsnprintf_s unknown &g

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #5, bug #40241 (project make): It worked for me, but of course I don't have your exact setup. I will have another look. (Don't worry about leaking memory, I just wanted to see if this kind of change fixes your problem. The actual change will have all this straightened up.) Th

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

Follow-up Comment #1, bug #40322 (project make): This doesn't happen for me. Does it happen for you always, or just with some Makefile's? Can you show an example of a Makefile and a session where Ctrl-C does not interrupt the Make run? There's special code in Make to handle the Ctrl-C situation

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

Follow-up Comment #4, bug #40322 (project make): That is not what is supposed to happen. When you press Ctrl-C, the SIGINT handler is invoked, this is the function fatal_error_signal defined on command.c. (Please verify that the signal handler is indeed invoked.) Since on Windows SIGINT handler

[bug #26075] $(wildcard) function holds parent directories open preventing deletes

Update of bug #26075 (project make): Status:None => Works for me Open/Closed:Open => Closed Fixed Release:None => 4.0 _

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #6, bug #40241 (project make): My patch did had 2 conceptual problems, sorry. Please try this patch instead. (file #29434) ___ Additional Item Attachment: File name: w32_unixy_shell.difSize:2 KB __

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #8, bug #40241 (project make): What does "doesn't handle quotes right" mean? It's a Unixy shell, right? What kind of shell are you using? BATCH_MODE_ONLY_SHELL cannot be catered to at this stage, it's something considered at a higher level. But that higher level doesn't know

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #10, bug #40241 (project make): I actually tested the patch with MSYS Bash. Can you show me one or two examples of it mishandling quotes? I use MSYS Bash quite a lot (although not from the native Make), and never saw any problems with quotes. And, btw, if you use MSYS Bash, wh

[bug #40344] Can't handle Windows path names longer than 259 characters

Update of bug #40344 (project make): Severity: 3 - Normal => 1 - Wish Item Group: Bug => Enhancement Triage Status:None => Major Effort Summary: Can'

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #14, bug #40241 (project make): Indeed, that's what I see as well. Can you use the MSYS file name notation instead, as in "/c/full/path/to/python.exe"? My testing indicates that the problem disappears when this format of file names is used. Btw, these are exactly the problems

[bug #40344] Can't handle Windows path names longer than 259 characters

Follow-up Comment #4, bug #40344 (project make): Make does not necessarily prepend the current directory, but the library functions it calls might do that internally, as part of file-name normalization. (So it's not the current directory that counts, but CURRENT_DIR/../../../../../../ in your cas

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #17, bug #40241 (project make): MSYS Make 3.82.90 from the URL below does work well with -jN: https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/ I use that build all the time. Yes, using single quotes are also a possibility. Eventually, I need to k

[bug #40241] CreateProcess failure with unixy paths

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

[bug #40344] Can't handle Windows path names longer than 259 characters

Follow-up Comment #5, bug #40344 (project make): For the record, the place where the long file name causes trouble is in name_mtime, where Make calls stat to get the file's time stamp. It looks like Windows prepends the current directory to the file name, without paying attention to the fact that

[bug #31150] The make doesn't work on Windows x64 platforms

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

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

Follow-up Comment #1, bug #16788 (project make): Paul, The OP suggests to replace this: #define ORDINARY_MTIME_MAX ((FILE_TIMESTAMP_S (NEW_MTIME) \ << FILE_TIMESTAMP_LO_BITS) \ + ORDINARY_MTIME_MIN + FILE_TIMESTAMPS_PER_S - 1) with this:

[bug #20542] Regression: windows gnumake + MKS shell + Special Shell Chars

Update of bug #20542 (project make): Item Group: Enhancement => None Open/Closed:Open => Closed ___ Follow-up Comment #3: 6 years have passed wi

[bug #15968] make fails trying to stat a .PHONY target: p\:foo

Update of bug #15968 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => 4.0 Summary: make

[bug #37648] [Regression from 3.81] Cannot build projects having files with German/French/other specific characters

Update of bug #37648 (project make): Item Group: Bug => Enhancement Triage Status: Need Info => Major Effort ___ Follow-up Comment #2: No further info is ava

[bug #40227] Various fixes for MSVC build of 4.0

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

[bug #40503] Shebang detection is flawed

Follow-up Comment #1, bug #40503 (project make): Detection of Unix scripts with shebang is a compatibility feature, meant for running Makefile's that invoke Unix shell scripts. On Unix, what follows the shebang is the absolute file name of the interpreter in Unix format, like "/bin/sh" or "/usr/l

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

Follow-up Comment #6, bug #40322 (project make): Any news on this? I don't want to leave a bug report that cannot be reproduced for prolonged periods of time. Thanks. ___ Reply to this item at: _

[bug #40503] Shebang detection is flawed

Update of bug #40503 (project make): Severity: 3 - Normal => 2 - Minor Item Group: Bug => Enhancement Assigned to:None => eliz

[bug #40503] Shebang detection is flawed

Follow-up Comment #3, bug #40503 (project make): It will slow down Make for no good reason, for starters. It also makes no sense with "absolute" paths such as /bin/sh. But the main reason is: this is an enhancement. Enhancements should come with a good reason why they would make sense, and aski

Re: a bug in make 4.0 for Microsoft Visual Studio

> From: "Akira Kakuto" > Date: Mon, 11 Nov 2013 22:20:51 +0900 > > I found a typo in output.c in make 4.0. > Please see an attached make40-msvc.diff. Thanks, this was already spotted and fixed in the repository. ___ Bug-make mailing list Bug-make@gnu.

<    1   2   3   4   5   6   7   8   9   >