[bug #47942] Random crash during compile time

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

[bug #48037] Build broken for windows

Update of bug #48037 (project make): Status:None => Works for me Assigned to:None => eliz Triage Status:None => Need Info _

[bug #48037] Build broken for windows

Update of bug #48037 (project make): Triage Status: Need Info => Small Effort ___ Follow-up Comment #3: The officially supported method of building Make with MinGW is by running the build_w32.bat batch f

[bug #48037] Build broken for windows

Follow-up Comment #5, bug #48037 (project make): The build_w32.bat script exists so that GNU Make could be easily built natively on Windows without all the development environment being available (since Make is an essential part of that environment). Anyway, feel free to submit patches for buildi

[bug #48037] Build broken for windows

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

Re: [PATCH][bug #48037] Add glob folder include to w32/Makefile.am

> From: Luke Allardyce > Date: Sat, 28 May 2016 00:11:51 +0900 > > Fixes windows build when compiling with make. > > diff --git a/w32/Makefile.am b/w32/Makefile.am > index b0b4734..53ba788 100644 > --- a/w32/Makefile.am > +++ b/w32/Makefile.am Thanks, pushed. __

Re: Some DJGPP specific fixes for Make 4.2.1 and later.

> Date: Sun, 12 Jun 2016 19:18:36 +0200 > From: "Juan Manuel Guerrero (juan.guerr...@gmx.de) [via dj...@delorie.com]" > > > - For systems like MSDOS, WINDOWS32 and other ones, the function > get_bad_stdin >is defined as a no-op macro in os.h but at the same time exists an >

Re: mingw32-make does not find prerequisites in VPATH when they have forward slashes

> From: Erasmo Aguilera > Date: Thu, 16 Jun 2016 18:35:17 -0600 > > I am working on a project with two directory trees: one for sources and > another for output files. I run > mingw-make from the source tree and add the output tree root to VPATH so that > their files can be found when > acting

Re: Simpler example of pathological behavior of directory caching

> From: Kyle Rose > Date: Thu, 6 Oct 2016 11:47:02 -0700 > Cc: bug-make@gnu.org > > $ make --version > GNU Make 4.2.1 > Built for i686-pc-linux-gnu > Copyright (C) 1988-2016 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is fr

Re: Simpler example of pathological behavior of directory caching

> From: Kyle Rose > Date: Thu, 6 Oct 2016 13:51:02 -0700 > Cc: psm...@gnu.org, bug-make@gnu.org > > On Thu, Oct 6, 2016 at 12:03 PM, Eli Zaretskii wrote: > > It works as you'd expect for me even on MS-Windows, as it did for Paul > on GNU/Linux, so I'm curi

Re: Unable to run make

> From: Steve Alphonse Siani > Date: Wed, 9 Nov 2016 10:39:27 -0500 > > I am unable to run "make" command. I Tried to reinstall everything in another > place but it still print the same > error: > > 1 [main] make 101064 child_info_fork::abort: > D:\Software\omnetpp-4.6\tools\win32\usr\bin\msys

Re: Incorrect parsing of DOS/Windows paths ??

> From: Paul Smith > Date: Sun, 18 Dec 2016 11:44:52 -0500 > > #ifdef HAVE_DOS_PATHS > /* For DOS paths, skip a "C:\..." or a "C:/..." until we find the >    first colon which isn't followed by a slash or a backslash. >    Note that tokens separated by spaces should be treated as se

Re: Incorrect parsing of DOS/Windows paths ??

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 18 Dec 2016 13:29:56 -0500 > > This function is called wherever the next thing the parser wants to see > is a list of files, and it wants to break them up into multiple > individual filenames. However, most of those places don't treat colons

Re: Incorrect parsing of DOS/Windows paths ??

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Tue, 20 Dec 2016 00:31:50 -0500 > > On Sun, 2016-12-18 at 22:10 +0200, Eli Zaretskii wrote: > > > Maybe it would be clearer what the issue was if we removed the second > > > colon: > > > > > &

[bug #50021] make hangs when it tries to execute script of less than 2 bytes in size

Update of bug #50021 (project make): Severity: 3 - Normal => 4 - Important Status:None => Fixed Open/Closed:Open => Closed Fixed Release:

Re: I need help

> From: Budi > Date: Wed, 15 Mar 2017 21:13:50 +0700 > > On Windows msys: this 'make' is ported to be 'make.exe' in msys package, > isn't it? I come accross a problem as I used to build using this > make.exe. Then I installed msys2 (64 bit version of msys) and build by > the same name but miss

Re: Improvement suggestion: listen to signals to adjust number of jobs

> Date: Tue, 23 May 2017 20:59:01 +0200 > From: Henrik Carlqvist > > My intention has been to make the patch work with > both Unix and Windows, but unfortunately I have no Windows machine to test > with. I'm not even sure if Windows supports bsd signals. If not, my > changes to w32/w32os.c should

Re: Improvement suggestion: listen to signals to adjust number of jobs

> Date: Tue, 23 May 2017 22:10:55 +0200 > From: Henrik Carlqvist > Cc: bug-make@gnu.org > > If Windows lack SIGUSR* I suppose that make does not support > toggling of debug output on Windows? Indeed, it doesn't. ___ Bug-make mailing list Bug-make@gnu.

Re: Need help with Windows port for GNU make (+ DOS pretesters)

> Date: Tue, 9 May 2000 10:18:19 -0400 (EDT) > From: "Paul D. Smith" <[EMAIL PROTECTED]> > > BTW, while Eli Zaretskii is still providing excellent support for the > DOS port of GNU make, it would be great if we had a few more pretesters > for this port, as w

Re: Make v3.79, for Windows32

On Thu, 15 Jun 2000, Andre Srinivasan wrote: > o Quoted expressions in shell commands don't seem to translate > across platforms. In the SunOS5.6 and Cygwin versions of > make 3.78.1, I could use the following: > > subdirs: $(DIRS) > if

Re: Make v3.79, for Windows32

> From: "Andre Srinivasan" <[EMAIL PROTECTED]> > Date: Thu, 15 Jun 2000 10:05:18 -0700 (GMT-8:00) > > I just checked that indeed bash is being invoked: > > $ cat Makefile > > all: > echo $$SHELL > > $ make > echo $SHELL > d:/cygnus/cygwin-b20/usr/loca

Make, suffix rules and pattern rules. (fwd)

I've verified on my system that suffix rules with prerequisites do seem to work, as in this example: .c.o: foo.h @echo $< Assuming you have foo.c and foo.h in your directory, type "make foo.o", and see Make echo the name "foo.c". Is something wrong with the assertion in the docs that "

Re: Make, suffix rules and pattern rules.

On Tue, 14 Nov 2000, Paul D. Smith wrote: > The thing is, they may have prerequisites but the prerequisites are > ignored. I think the manual should tell this. If you agree, I will send patches for the docs. ___ Bug-make mailing list [EMAIL PROTECTE

Re: (no subject)

> From: "Paul D. Smith" <[EMAIL PROTECTED]> > Date: Mon, 8 Jan 2001 17:42:28 -0600 > > CSRC = $(foreach file,$(CSRCLIST),$(if $(wildcard $(subst > \,/,$(file))),$(file),$(MAIN_IP_DIR)\$(file))) > > to check the existance of a specific file. > My problem with wildcard is that it is case-sensit

Re: make for windows use the incorrect date for update check

On Fri, 12 Jan 2001, Paul D. Smith wrote: > Make use the creation time instead the modification time for update check. ??? Is that a question? Can we possibly have more info, including some motivation? ___ Bug-make mailing list [EMAIL PROTECTED] h

Re: Bug under Win32 with gnumake 3.79.1 and 3.77

> From: "Paul D. Smith" <[EMAIL PROTECTED]> > Date: Tue, 11 Sep 2001 17:19:44 +0200 > > X=$(wildcard c:\\*.*) > does not macht anything under win32 while > X=$(wildcard c:/*.*) > does match the given files. > This is a problem for me, since make does > use the "\\" as the path separator internall

Re: make signal text descriptions

> Date: Wed, 29 Oct 2003 21:07:39 + > From: "J. Grant" <[EMAIL PROTECTED]> > > ok, I've cc [EMAIL PROTECTED], so maybe someone can tell me if signal > numbers are decoded. Would you include this internally? or use a lib etc? The signal names are decoded if the underlying library supports th

Re: make signal text descriptions

> Date: Thu, 30 Oct 2003 00:02:55 + > From: "J. Grant" <[EMAIL PROTECTED]> > > I noticed on this list list they talk about it being a failed exec: > > http://www.cygwin.com/ml/cygwin/2003-06/msg00674.html I doubt if this is a signal. It's more probably an error code from a library function

Re: [patch] README.W32.template

> Date: Sat, 22 Nov 2003 21:00:42 -0500 > From: "Paul D. Smith" <[EMAIL PROTECTED]> > > Note that this can't be done on Windows, only on UNIX. Well, anyway, > I've never done it on Windows and I've never heard of anyone who has. > The tools required to build from the CVS archive (GNU m4, Perl, GN

Re: GNU Make 3.79.1 Bug-Report?

> From: "Gerd Igelmann" <[EMAIL PROTECTED]> > Date: Tue, 20 Jan 2004 20:14:27 +0100 > > all: > cd test > dir > content.txt > cd .. > > Make 3.76.1 does the change of directory as expected, make 3.79.1 does not As Paul points out, this is most probably a shell issue, not a Make

Re: GNU Make 3.79.1 Bug-Report?

> Date: Tue, 20 Jan 2004 21:47:21 -0500 > From: "Paul D. Smith" <[EMAIL PROTECTED]> > > In Windows and DOS, the COMMAND.COM works differently in that the > current working directory value is global, to some extent, so any change > to it, in any process, effects future processes. Actually, it's no

Re: Schedule for GNU make 3.81

ath function replaces any backslashes in the DOS/Windows file names with forward slashes; perhaps this side effect (which I think is a feature) should be mentioned in make.texi. Finally, please make sure dosbuild.bat has DOS line endings after you apply the diffs below. (Otherwise, some DOS/Win

Re: Schedule for GNU make 3.81

> Date: Sat, 19 Feb 2005 17:42:42 -0500 > Cc: bug-make@gnu.org > From: "Paul D. Smith" <[EMAIL PROTECTED]> > > ez> 5. On variable.c, the function define_automatic_variables used to > ez>always export SHELL (there was a line "v->export = v_export;" right > ez>after SHELL was assigned

Re: Schedule for GNU make 3.81

> Date: Wed, 16 Feb 2005 01:45:41 -0500 > From: [EMAIL PROTECTED] > > http://make.paulandlesley.org/make-3.81beta2.tar.bz2 > http://make.paulandlesley.org/make-3.81beta2.tar.gz Here's an annoyance with this beta version when I build it with DJGPP and GCC 3.3.3 or 3.4.3: gcc -I. -I. -I.

Re: Schedule for GNU make 3.81

> Date: Mon, 21 Feb 2005 08:37:38 -0500 > Cc: bug-make@gnu.org, make-w32@gnu.org > From: "Paul D. Smith" <[EMAIL PROTECTED]> > > ez> file.c: In function `file_timestamp_cons': > ez> file.c:554: warning: comparison is always true due to limited range > of data type > > Unfortunately there

Re: GNU make 3.81beta4 released

section. I suggest the following changes to make.texi and NEWS: 2005-12-17 Eli Zaretskii <[EMAIL PROTECTED]> * doc/make.texi (Execution): Add a footnote about changes in handling of backslash-newline sequences. Mention the differences on MS-DOS and MS-Windo

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #6, bug #15718 (project make): Please try the pretest version of Make 3.81 (beta4). This problem should be fixed in that version. ___ Reply to this item at:

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #7, bug #15718 (project make): Let me clarify: Comment #6 is for Doug Konrad. ___ Reply to this item at: ___

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #8, bug #15718 (project make): Here's a response to Comments #2 and #5: It's not true that ``SHELL variable assignment within Makefile doesn't work for Win32 port of GNU make''. It's just that it's a bit tricky, and also your test Makefile was too simple to force Make to invok

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #10, bug #15718 (project make): I'm not sure it's a bug in the Windows port that an arbitrary value of SHELL does not immediately "goto slow"; after all, it's hard to imagine radically different quoting rules for the relatively simple-minded shells we have on WIndows. But I wil

Re: make 3.81rc1 / MSYS

> From: David Ergo <[EMAIL PROTECTED]> > Date: Tue, 28 Feb 2006 13:08:10 +0100 > Cc: Xavier Marichal <[EMAIL PROTECTED]>, > =?ISO-8859-1?Q?S=E9bastien?= Frippiat <[EMAIL PROTECTED]> > I managed to compile a working version of make 3.81rc1 for MSYS but I > had do some modifications. > > first

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #14, bug #15718 (project make): Paul is right: the Windows port does not invoke cmd.exe with the -c switch. So there's no bug here and nothing to fix. Here are the gory details: If you look closer at job.c:construct_command_argv_internal, you will see that, in the `slow' case

Re: [bug #15718] Weird behavior of the SHELL variable on Win32

> Date: Sat, 4 Mar 2006 20:17:20 +0200 > From: Eli Zaretskii <[EMAIL PROTECTED]> > > The fact that it doesn't work with setting SHELL from the command line might > mean there's another place in the code where the special treatment of cmd > should be added.

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #19, bug #15718 (project make): The real bugs wrt SHELL that still need to be worked on are: 1. When the Windows port searches along PATH for a shell whose name is not cmd, it does not try to append the executable extensions, so SHELL=foo would not find foo.exe 2. If the value

Re: make 3.81rc1 / MSYS

> From: David Ergo <[EMAIL PROTECTED]> > Cc: bug-make@gnu.org, Xavier Marichal <[EMAIL PROTECTED]>, > =?ISO-8859-1?Q?S=E9bastien?= Frippiat <[EMAIL PROTECTED]> > Sorry, but as a understand the code, sh_chars_sh is an intermediate > variable as sh_chars_dos is, and sh_chars is the real varia

Re: make 3.81rc1 / MSYS

> From: David Ergo <[EMAIL PROTECTED]> > Cc: bug-make@gnu.org, Xavier Marichal <[EMAIL PROTECTED]>, > =?ISO-8859-1?Q?S=E9bastien?= Frippiat <[EMAIL PROTECTED]> > Date: Tue, 07 Mar 2006 09:28:46 +0100 > > Ok, now I understand. But for MSYS, as it uses unix code, sh_chars_sh is > not defined

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #16, bug #15718 (project make): Thanks. Does it work if you put SHELL=cmd inside the Makefile? That does work for me. The fact that it doesn't work with setting SHELL from the command line might mean there's another place in the code where the special treatment of cmd shoul

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #17, bug #15718 (project make): Okay, I've found the culprit: setting SHELL from the command-line arguments wasn't handled as setting it from the Makefile. I think that's a bug (the Unix version doesn't handle SHELL in any special way when it comes from the command line), so I

[bug #16132] Quoting problem in 3.81rc1

Follow-up Comment #2, bug #16132 (project make): I cannot reproduce this, either, on Windows XP. I tried with and without a Unixy sh.exe on my PATH, and both behave as expected, identically to v3.80 and v3.80b4. (The behavior with and without sh.exe is not identical, but that's because the `ech

[bug #16132] Quoting problem in 3.81rc1

Follow-up Comment #11, bug #16132 (project make): The result without sh.exe is the expected one. So Make is working correctly, and the problem is is (in)compatibility with the Cygwin shell. When I need a Unixy shell, I use the old port of zsh. You should be able to find it on the net (sorry, I

[bug #16132] Quoting problem in 3.81rc1

Follow-up Comment #13, bug #16132 (project make): Did the OP build the previous versions of Make with the same compiler as the release candidate? If not, perhaps therein lies the reason for the difference, especially if the other versions are Cygwin ports (as opposed to to rc1 that was built wit

[bug #16132] Quoting problem in 3.81rc1

Follow-up Comment #18, bug #16132 (project make): Then I suggest that you try replacing the shell as well. As I already wrote, I cannot reproduce this with my version of sh.exe. Alternatively, you could try to debug this and see where exactly the problem lies. If you can afford spending some t

[bug #16132] Quoting problem in 3.81rc1

Follow-up Comment #16, bug #16132 (project make): Yes, I'm the same Eli Z. Paul is correct asking you for the details of the old versions: how they were built and with what compier. ___ Reply to this item at:

[bug #16132] Quoting problem in 3.81rc1

Follow-up Comment #21, bug #16132 (project make): Thanks, Pieter. This means there's no bug at all: the comments inside config.h.W32 clearly say to define HAVE_CYGWIN_SHELL if you are using such a shell. (Paul, do you think we should emphasize this in README.W32?) I don't know why "echo" is de

Re: Contradicting license informations in make.texi

> Date: Sun, 26 Mar 2006 13:14:49 +0200 > From: Sven Joachim <[EMAIL PROTECTED]> > > 1) Version b) lists the ``GNU General Public License'' as an Invariant > Section, but does not actually include it. It should mention the GFDL section (which _is_ included) instead. I'm guessing that when th

Re: Problem with overriding def. SHELL-sh.exe on W2000

> Date: Mon, 27 Mar 2006 23:05:41 +0200 > From: [EMAIL PROTECTED] > > I'm using gnumake 3.78 (also tried 3.8) buided with VC on W2000. > I've a problem with overriding default SHELL value from sh.exe to cmd.exe. Yes, this is a known problem with Make on Windows. I believe it has been corrected i

Re: Probable Spam: make 3.81 cannot build gcc 4.x.y

> Date: Mon, 03 Apr 2006 14:25:12 +0400 > From: =?KOI8-R?Q?=E4=C5=CA=D4=C5=D2_=E1=CC=C5=CB=D3=C1=CE=C4=D2_=F7=C1?= > =?KOI8-R?Q?=CC=C5=D2=C9=C5=D7=C9=DE?= <[EMAIL PROTECTED]> > > After update GNU make from 3.80 up to 3.81 i cannot build gcc 4.0.2, > 4.0.3 and 4.1.0 whith same error: > > rm

Re: [bug #16286] VPATH and directory cache

> Date: Thu, 6 Apr 2006 16:33:04 -0400 > From: "Paul D. Smith" <[EMAIL PROTECTED]> > Cc: > > All of the behavior you're seeing is explained in my webpages referenced > earlier. Given the number of times this comes up in various forums and in the bug tracker, would it be a good idea to include i

[bug #16362] Regression: make -n causes $(shell) failure on Windows

Follow-up Comment #1, bug #16362 (project make): Sounds like I should stop trying to maintain the Windows port, as I cause more trouble than help. ___ Reply to this item at:

[bug #16476] Inconsistent function macros - again

Follow-up Comment #3, bug #16476 (project make): AFAIK, WINDOWS32 is used because the GNU Project doesn't like to be part of those who say that MS-Windows is ``a win''. Therefore, we cannot remove WINDOWS32 and use _WIN32 instead. As for its usage policy, WINDOWS32 should be used for OS- and ru

[bug #16505] Line-continuation backslashes are not stripped

Follow-up Comment #1, bug #16505 (project make): This is not a regression, but a deliberate change whose purpose is to follow the Posix specifications. From NEWS: - quotation -- * WARNING: Backward-incompatibility! In order to comply with POSIX, the way in whic

[bug #16505] Line-continuation backslashes are not stripped

Follow-up Comment #6, bug #16505 (project make): The Posix behavior has its merits: without it, how does one pass a command line with embedded newlines from a Makefile? The Posix handling of newlines in single quotes permits this. ___ Re

[bug #16505] Line-continuation backslashes are not stripped

Follow-up Comment #11, bug #16505 (project make): I can understand everything you are saying -- the backward incompatibility, the suggestion to add an explicit warning, the works. The only thing I do NOT understand is why do you insist on telling about the EOF error etc., when you have at least

Re: Windows XP and make 3.80

> Date: Fri, 05 May 2006 10:14:38 -0400 > From: =?ISO-8859-1?Q?Pablo_Alarc=F3n_Pavez?= <[EMAIL PROTECTED]> > > Command: make clean > OS: Windows XP version 2002, service pack 2 > make version: 3.80 > > It interprets "rmdir /q /s lib" as rmdir /q, rmdir /s and rmdir lib with > errors. Do you hav

[bug #16562] Backslashes copied from Makefile to Shell (3.80 behaved differently)

Follow-up Comment #2, bug #16562 (project make): It _is_ possible to pass multiline arguments to the shell: either use double quotes instead of single quotes, or introduce a variable whose value is the multiline argument. (The latter works because the new Posix-compliant behavior retains backsla

[bug #16362] Regression: make -n causes $(shell) failure on Windows

Follow-up Comment #3, bug #16362 (project make): The following patch fixes this bug: --- function.c~02006-04-01 12:36:40.0 +0300 +++ function.c 2006-05-27 15:58:26.984375000 +0300 @@ -1589,12 +1589,25 @@ func_shell (char *o, char **argv, const int pid; #ifndef __MSDOS__ +

Re: Bug in builtin function abspath (again)

Incidentally, shouldn't we emulate realpath's failures in func_realpath on systems that don't have realpath? AFAIK, realpath fails if the file does not exist, so perhaps we should stat the result of abspath on such systems and return an NULL if it fails. WDYT? __

Re: Bug in builtin function abspath (again)

> Date: Tue, 30 May 2006 10:49:17 -0400 > Cc: bug-make@gnu.org > From: "Paul D. Smith" <[EMAIL PROTECTED]> > > > The realpath function will resolve both absolute and relative paths > > and return the absolute pathname corresponding to pathname. All but > > the last component of pathname must exist

Re: Bug in builtin function abspath (again)

> From: Boris Kolpackov <[EMAIL PROTECTED]> > Date: Wed, 31 May 2006 07:48:12 + (UTC) > > I just checked the page for realpath in SUS and I don't see anything > that implies this. My understanding that all components of the path > must exist. So it's probably system-dependent. > > Yes, that

Re: bug when redirecting mingw32-make output (w32/sub_proc/sub_proc.c)

> From: Roland Puntaier <[EMAIL PROTECTED]> > Date: Fri, 2 Jun 2006 17:36:00 +0200 > > "process_easy: DuplicateHandle(In) failed" is issued, when redirecting the > mingw32-make output from a parent process. > > GetStdHandle returns 0, which is not an error, but also no handle to be > duplicated

[bug #17105] problem colon after drive letter in prerequisite

Follow-up Comment #1, bug #17105 (project make): This problem doesn't happen with the native Windows build of Make 3.81. If you rewally need to use the Cygwin build, I suggest to take this up with the Cygwin maintainers: I don't know whether the Cygwin version is supposed to support file names w

Re: 3.81 and windows paths

> Date: Thu, 27 Jul 2006 17:09:16 -0400 > From: "Paul D. Smith" <[EMAIL PROTECTED]> > Cc: cygwin@cygwin.com, bug-make@gnu.org > > I believe that this support is limited to handling drive letters without > choking on the ":", actually: IIRC the native support still requires > forward slashes (/) ra

Re: 3.81 and windows paths

> Date: Fri, 28 Jul 2006 17:31:31 -0400 > From: "Paul D. Smith" <[EMAIL PROTECTED]> > Cc: > > Hm. I just can't think of any but the most obscure cases where this is > true. The DOS pathname handling in vanilla GNU make, as far as I know, > is very specific: if and ONLY if the first character of

Re: syntax error vpath.c line 348

> Date: Mon, 31 Jul 2006 16:16:53 +0200 (MEST) > From: "Stefan Renz"<[EMAIL PROTECTED]> > > I just tried to build gnu make for win32 and got an error message like this: > > syntax error vpath.c line 348 > There are too many actual parameters etc. > > I changed it from > n = rindex(*file,, '\\')

[bug #17381] Compile errors under DJGPP

Follow-up Comment #1, bug #17381 (project make): The following patch should take care of this: 2006-08-12 Eli Zaretskii <[EMAIL PROTECTED]> * job.h [__MSDOS__]: Use the same prototype for child_execute_job as __EMX__ does. --- job.h~0 2006-02-12 02:16:04.0

Re: [bug #17381] Compile errors under DJGPP

;child_execute_job': > job.c:1931: error: void value not ignored as it ought to be Thanks. Here's a patch to fix this: 2006-08-12 Eli Zaretskii <[EMAIL PROTECTED]> * job.h [__MSDOS__]: Use the same prototype for child_execute_job as __EMX__ does. --- job.h~

[bug #17521] target-specific variables inluding semicolon

Follow-up Comment #1, bug #17521 (project make): This is not a bug, but a documented change in behavior, intended to bring GNU Make in line with Posix specification for Make. >From the NEWS file: * WARNING: Backward-incompatibility! In order to comply with POSIX, the way in which GNU make pro

Re: filenames with colons in them

> From: Dan Jacobson <[EMAIL PROTECTED]> > Date: Mon, 28 Aug 2006 17:50:58 +0800 > > P.S., in the Info index, lines with :: are unchoosable: > byte-code: No such node or anchor: rule, double-colon ( Please give an example of such an index entry in the Make manual (or any other manual).

Re: make 3.60: BS/NL mishandled with non-default SHELL

> From: Andreas Schwab <[EMAIL PROTECTED]> > Date: Mon, 28 Aug 2006 16:07:37 +0200 > Cc: [EMAIL PROTECTED] > > The following makefile causes a syntax error, but works correctly when the > first line is commented out. Did you really mean "make 3.60"? _

[bug #17572] Using Windows pathnames fail

Follow-up Comment #1, bug #17572 (project make): I cannot reproduce this with a native Windows build of Make 3.81. I get the expected message: make: *** No rule to make target `C:/Folder', needed by `target.o'. Stop. What port of Make did you use, and where did you get the binary? If you you

Re: filenames with colons in them

> From: Dan Jacobson <[EMAIL PROTECTED]> > Date: Tue, 05 Sep 2006 03:15:52 +0800 > > In the make concept index, I hit RET upon > * :: rules (double-colon): Double-Colon.(line 6) > and I get > byte-code: No such node or anchor: : rules (double-colon): Double-Colon > here in

Re: make cannot handle prerequisites that contain a colon

> From: Bas Holleman <[EMAIL PROTECTED]> > Date: Fri, 29 Sep 2006 10:01:16 + (UTC) > > Hi Sebastien, > > About the problem: gmake begin_process CreateProcess failed. I cannot find the beginning of this thread in the archives. > This is my experience: The Windows PATH variable is to long. gm

Re: make cannot handle prerequisites that contain a colon

> Date: Mon, 2 Oct 2006 15:22:04 +0200 > From: "Holleman, Bas" <[EMAIL PROTECTED]> > > Yes, that is true. On Windows, the PATH environment variable can have > more than 256 characters. And I think it is the problem and something > like this happens if PATH is to long: gmake can not handle so much

Re: SHELL -c hardwired

> From: Dan Jacobson <[EMAIL PROTECTED]> > Date: Sun, 29 Oct 2006 08:02:17 +0800 > > One can set SHELL, but there's no way to get rid of the "-c" in case one > wants too. E.g., one wants to make SHELL=mysql as an experiment etc. > mysql would need a -e, etc. Doesn't it work to customize shell-fil

Re: SHELL -c hardwired

> From: Dan Jacobson <[EMAIL PROTECTED]> > Date: Mon, 06 Nov 2006 05:58:15 +0800 > > >> One can set SHELL, but there's no way to get rid of the "-c" in case one > >> wants too. E.g., one wants to make SHELL=mysql as an experiment etc. > >> mysql would need a -e, etc. > > EZ> Doesn't it work to cu

Re: Tiny project to play with gmake ?

> Date: Wed, 15 Nov 2006 13:23:31 +0200 > From: "Maxim Vexler" <[EMAIL PROTECTED]> > > To make a good starting point I'm looking for a small ("tiny") open > source project, one with a few cpp files, some small .h files. A bonus > would be if this project uses a small but stable (compile wise) 3rd

Re: File path bug on windows platform

They currently only work on Posix platforms. I hope to have that fixed in the next release. In fact, I have a preliminary patch to fix that, so if you need this ASAP, and can rebuild Make from sources on your machine, please try the patch below and tell me if it works for you. 2006-05-27 Eli Z

Re: Problem with CURDIR variable

> From: Paul Smith <[EMAIL PROTECTED]> > Date: Mon, 11 Dec 2006 19:42:51 -0500 > Cc: bug-make@gnu.org > > This test is kind of strange. Unless there's some specific reason the > makefile REQUIRES the CURDIR variable to be set by make, it should be > rewritten: > > ifndef CURDIR > $(error Please

Re: Bug: make igores options, switches and targets

> Date: Thu, 18 Jan 2007 22:28:12 +0100 > From: Georg-Johann Lay <[EMAIL PROTECTED]> > > I have some trouble with GNU make. The make comes from WinAVR, a > distribution of avr-gcc for Win32, i.e. mingw. It is the most recent > build from 2006-04-21 But the output you show from "make --version",

Re: Q: On Windows why not ignore CRLF?

> From: Paul Smith > Date: Wed, 31 May 2017 19:48:57 -0400 > > I'm working on ensuring that the test suite works on Windows That's great news, thanks! > #if !defined(WINDOWS32) && !defined(__MSDOS__) && !defined(__EMX__) >    /* Check to see if the line was really ended with CRLF; if so

Re: Q: On Windows why not ignore CRLF?

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Fri, 02 Jun 2017 15:56:51 -0400 > > FYI, I don't know how "good" this is for testing requirements but on my > Windows systems I've installed Git for Windows (along with Perl of > course) and that provides a number of UNIX commands which is why I >

Re: Crash on Windows when SHELL is assigned

> From: Orgad Shaneh > Date: Mon, 5 Jun 2017 23:13:26 +0300 > > 1 You must use a full name for SHELL, including the extension (SHELL=sh > doesn't work. SHELL=sh.exe > does, if sh.exe exists in PATH). PATHEXT should be used for the executable > detection. Can you tell why this is a problem? T

Re: Crash on Windows when SHELL is assigned

> Date: Tue, 06 Jun 2017 20:18:45 +0300 > From: Eli Zaretskii > Cc: bug-make@gnu.org > > > 2 It looks like if PATH contains quotes, they're treated in a strange > > manner. Instead of just removing > > (unescaping) them, make looks for \"some director

Re: Crash on Windows when SHELL is assigned

> From: Orgad Shaneh > Date: Tue, 6 Jun 2017 20:49:26 +0300 > Cc: bug-make@gnu.org > > > Can you tell why this is a problem? There's no equivalent of PATHEXT > > on Posix systems, and no one coded anything like that for Windows. Is > > it really such a serious problem? If so, in what use cases

Re: Crash on Windows when SHELL is assigned

> From: Orgad Shaneh > Date: Tue, 6 Jun 2017 22:08:08 +0300 > Cc: bug-make@gnu.org > > > OK, I see it. Please try the patch below; if it gives satisfactory > > results, I will push it to the Make repository for the next release. > > > > --- variable.c~02016-05-21 23:22:32.0 +0300

[bug #51237] Deadlock in Ctrl-C handler on Windows

Follow-up Comment #1, bug #51237 (project make): Thanks for the analysis and the patch. Your patch is too large to accept without legal paperwork. Would you be willing to assign copyright for your changes to the FSF, so we could accept your contribution? If so, I can send you the legal form and

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Thu, 15 Jun 2017 22:33:30 +0300 > > When I abort a build, make fails to unlink the intermediate files. I > previously used 4.1.90, and I don't remember > having these problems. > > This happens even for a single job (without -j). > > Output: > main.cpp > mingw32-ma

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Fri, 16 Jun 2017 00:46:34 +0300 > > Ok, I found out that the bug is not (entirely) in make. What causes this > problem is the following patch applied > by MSYS2 packages of mingw make: > > diff -Naur make-4.2.1/main.c make-4.2.1.new/main.c > --- make-4.2.1/main.c 20

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Fri, 16 Jun 2017 01:16:09 +0300 > > ... or not. I still get it even without this patch, when running from IDE. > Reverting the patch only fixes the issue > when running in command line. > > I did file a bug[1], but this is not the real reason. Probably timing issue.

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Fri, 16 Jun 2017 11:49:33 +0300 > Cc: bug-make@gnu.org > > I'd certainly like to know why "setlocale interferes with line > buffering if using parallel make on MinGW". Could you perhaps ask the > MSYS2 maintainers to report their findings here or on make-w32? > >

<    1   2   3   4   5   6   7   8   9   >