Re: Inconsistent behaviour when building in parallel

> From: Dirk Heinrichs <[EMAIL PROTECTED]> > Date: Sat, 20 Jan 2007 22:22:04 +0100 > > So the left hand doesn't know what the right hand does? ??? Would you care to explain where do you see two hands that don't know each what the other one does? As far as I see from Paul's clear description is t

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

Follow-up Comment #1, bug #18872 (project make): You are using the Cygwin build of Make 3.81, which does not support drive letters in file names (I believe the announcement on the Cygwin mailing list at the time they released Make 3.81 explains why they discontinued support for drive letters.) I

Re: Parallel Jobs Bug

> From: Paul Smith <[EMAIL PROTECTED]> > Date: Sun, 28 Jan 2007 09:42:25 -0500 > Cc: bug-make@gnu.org > > > * the code that generates that output is conditionally compiled > only if MAKE_JOBSERVERS is set, and that macro is set only if > the configure script detects a number

Re: BUG while running the make file

> Date: Wed, 7 Feb 2007 11:51:56 -0500 > From: "Raheja, Himanshu" <[EMAIL PROTECTED]> > > gcc -I.. -I. -I./include -I./common -D_FILE_OFFSET_BITS=64 > -I/usr/include -g -W -Wall -Werror -Wno-unused -g -O2 > -D_FILE_OFFSET_BITS=64 -g -W -Wall -Werror -Wno-unused -DHAVE_CONFIG_H > -c ./common/linksu

Re: automake-1.10 can't work with make-3.81 in Mingw in Windows XP

> Date: Sat, 24 Feb 2007 18:04:28 +0800 (CST) > From: haibin zhang <[EMAIL PROTECTED]> > Cc: > > Hi all: > automake-1.10 can't work with make-3.81 in Mingw in Windows XP, but > automake-1.9.6 can work with make-3.81. > > I tested that automake-1.10 can work with make-3.79.1 in Mingw in Windows

Re: make problems

> From: "Turbo-parts" <[EMAIL PROTECTED]> > Date: Thu, 1 Mar 2007 23:03:56 +0100 > > Hello, allways no targets specified and no makefile found. stop. This usually means that you don't have a file called Makefile in the current directory. ___ Bug-make

[bug #19448] Re-exec after "include file rebuild" is more dependent on filesystem timestamps than strictly necessary.

Follow-up Comment #5, bug #19448 (project make): What Christopher suggests might work, in principle, for Make jobs that are performed sequentially. But what about parallel execution, where several targets are remade asynchronously? Either we rely on the filesystem to record time of creation for

Re: timestamp resolution

> Date: Thu, 3 May 2007 23:20:31 +0100 > From: "James Youngman" <[EMAIL PROTECTED]> > Cc: bug-make@gnu.org, > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > [ CC += bug-make@gnu.org ] > > On 5/3/07, Ulrich Drepper <[EMAIL PROTECTED]> wrote: > > On today's call we agreed on the following propos

Re: Build warnings in CVS make 3.81.90

> From: Paul Smith <[EMAIL PROTECTED]> > Date: Fri, 11 May 2007 15:15:34 -0400 > Cc: GNU Make > > > function.c: In function 'func_shell': > > function.c:1597: warning: variable 'error_prefix' might be clobbered by > > 'longjmp' or 'vfork' > > function.c:1589: warning: argument 'o' might be clobb

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

Follow-up Comment #1, bug #20542 (project make): Sorry, I cannot reproduce this with a (non-MKS) port of a Unix shell. So this looks like a problem specific to MKS. If you can step through the function that invokes external programs (process_begin, defined on w32/subproc/sub_proc.c) and its subr

[bug #20550] Crash with setting SHELL from the commandline

Follow-up Comment #1, bug #20550 (project make): Thanks. I believe this was already reported, and the attached patch (already sent to the maintainer) should fix it. (file #13412) ___ Additional Item Attachment: ___

[bug #20549] make -n doesn't work recursively

Follow-up Comment #1, bug #20549 (project make): Thanks. I believe the attached patch should take care of this bug. Does it? (file #13414) ___ Additional Item Attachment: ___ R

Re: [bug #20549] make -n doesn't work recursively

I believe the following patch should fix this problem (uploaded to Savannah as well): 2007-07-21 Eli Zaretskii <[EMAIL PROTECTED]> * function.c (func_shell): Call construct_command_argv with zero value of FLAGS. * job.c (construct_command_argv_internal): New ar

[bug #20550] Crash with setting SHELL from the commandline

Follow-up Comment #3, bug #20550 (project make): Did you try to patch the current CVS? Because I'm not even sure it compiles on Windows (never tried it myself), and the place GCC complains doesn't seem to have anything in common with the patch I sent. Anyway, can we take this to the mailing lis

[bug #20549] make -n doesn't work recursively

Follow-up Comment #3, bug #20549 (project make): Your report was relative to Make 3.81, and the diffs are relative to that version. I don't track the CVS, and am not even sure it compiles on Windows. Please, let's continue discussing this on one of the Make mailing lists ([EMAIL PROTECTED], [EM

[bug #20550] Crash with setting SHELL from the commandline

Follow-up Comment #4, bug #20550 (project make): Sorry, I meant bug-make, not bug-gnu-emacs, of course. ___ Reply to this item at: ___ Message sent vi

Re: problem with GNU make configure

> Date: Fri, 3 Aug 2007 14:52:53 -0700 (PDT) > From: [EMAIL PROTECTED] > > I am trying to configure GNU make from cygwin and ./configure doesn't run. > I have attached the cygwin console capture with the error. I see no attachments. ___ Bug-make maili

Re: problem with GNU make configure

> Date: Fri, 3 Aug 2007 14:55:15 -0700 (PDT) > From: [EMAIL PROTECTED] > > oops, here is the attached console capture It's much better to send this as plain text (you can capture it with `tee' or even by copying and pasting the contents into your mailer). My crystal ball says that somehow the co

Re: Switching from CVS to GIT

> Date: Sat, 13 Oct 2007 13:59:43 -0400 > From: Christopher Faylor <[EMAIL PROTECTED]> > Cc: > > Isn't there a pure MinGW (not msys) version too? If someone knows where to get it, please tell. ___ Bug-make mailing list Bug-make@gnu.org http://lists.g

Re: Switching from CVS to GIT

> From: Paul Smith <[EMAIL PROTECTED]> > Date: Sat, 13 Oct 2007 12:37:46 -0400 > Cc: > > I'm considering switching from CVS to another form of SCM. Can you tell why? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug

Re: Switching from CVS to GIT

> From: Benoit SIGOURE <[EMAIL PROTECTED]> > Date: Sat, 13 Oct 2007 19:18:42 +0200 > Cc: Make Windows <[EMAIL PROTECTED]>, bug-make > > I frequently read Git's ML and it seems rather stable on Cygwin. Which for me is a turn-off, because I don't want to install Cygwin. > The MSYS version should

Re: Switching from CVS to GIT

> From: Benoit SIGOURE <[EMAIL PROTECTED]> > Date: Sat, 13 Oct 2007 20:52:58 +0200 > Cc: bug-make > > On Oct 13, 2007, at 7:59 PM, Christopher Faylor wrote: > > > Isn't there a pure MinGW (not msys) version too? > > > > This sounds unlikely because many commands in git-core are shell > script

Re: Switching from CVS to GIT

> Cc: Make Windows <[EMAIL PROTECTED]>, > bug-make > From: Benoit SIGOURE <[EMAIL PROTECTED]> > Date: Sat, 13 Oct 2007 22:09:56 +0200 > > > Is there a good native Windows port of GIT? > > http://git.or.cz/gitwiki/WindowsInstall Thanks, I already found that page. However, it sounds like it onl

Re: Switching from CVS to GIT

> From: Paul Smith <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], bug-make@gnu.org > Date: Sun, 14 Oct 2007 12:57:20 -0400 > > On Sat, 2007-10-13 at 21:10 +0200, Eli Zaretskii wrote: > > Can you tell why? > > The main reasons are lack of functionality in

Re: possible memory leak in make 3.81

> Date: Mon, 15 Oct 2007 20:12:37 +0100 > From: Jon Grant <[EMAIL PROTECTED]> > Cc: bug-make@gnu.org > > Paul Smith wrote on 14/10/07 22:17: > > On Sun, 2007-10-14 at 18:33 +0100, Jon Grant wrote: > >> Do they get free'd up when make exits? > > > > No. It's quite difficult to do this since the v

Re: Switching from CVS to GIT

> Date: Mon, 15 Oct 2007 13:36:53 -0700 > From: Howard Chu <[EMAIL PROTECTED]> > Cc: bug-make@gnu.org, [EMAIL PROTECTED] > > IMO the objections to requiring MSYS/Cygwin on Windows made no sense in this > discussion. Believe me, it does make sense to some. In a nutshell, if you use Cygwin or MSY

Re: Config.h and pid redefinition...

> Date: Sat, 8 Dec 2007 21:18:55 +0100 > From: "Alberto Santini" <[EMAIL PROTECTED]> > > I compiled make 3.81 on Windows box Vista using MingW - gcc (GCC) > 4.2.1-sjlj (mingw32-2). > > I modified "config.h.W32" commenting the line 412: > #define pid_t int > > So it would be better to add a condi

Re: Invalid opton --B

> Date: Mon, 10 Dec 2007 17:07:36 -0800 > From: "Anand, CJ" <[EMAIL PROTECTED]> > > The command we use is > > make OS=nto CPULIST=x86 -B install LDFLAGS=-M > > The error we get is > > make: invalid option - B What does "make --version" say? ___ Bug

Re: Config.h and pid redefinition...

fig.h (see make.h, for instance) is > loaded before sys/types.h Yes, that was silly of me. How about the patch below, then? > I think the solution is using GCC_VERSION. :( I don't want to use GCC_VERSION, because then I'd need to know exactly which version st

Re: Config.h and pid redefinition...

> #define _PID_T_ > typedef int _pid_t; > > #ifndef _NO_OLDNAMES > typedef _pid_tpid_t; > #endif > #endif /* Not _PID_T_ */ Thanks. Could you please try the patch below, and see if it fixes your original problem? 2007-12-15 Eli Zaretskii <[EMAIL P

Re: Config.h and pid redefinition...

> Date: Sun, 16 Dec 2007 11:08:41 +0100 > From: "Alberto Santini" <[EMAIL PROTECTED]> > Cc: bug-make@gnu.org > > I confirm you the patch works fine. > > > 2007-12-15 Eli Zaretskii <[EMAIL PROTECTED]> > > > >* config.h.W32: Inclu

Re: Config.h and pid redefinition...

> Date: Sun, 16 Dec 2007 11:08:41 +0100 > From: "Alberto Santini" <[EMAIL PROTECTED]> > Cc: bug-make@gnu.org > > I confirm you the patch works fine. > > > 2007-12-15 Eli Zaretskii <[EMAIL PROTECTED]> > > > >* config.h.W32: Inclu

Re: Fixing broken djgpp support in make 3.81

atches below. Thanks again for your efforts supporting DJGPP ports in general, and Make in particular. 2007-12-22 Eli Zaretskii <[EMAIL PROTECTED]> Suggested by Juan Manuel Guerrero <[EMAIL PROTECTED]>: * Makefile.DOS.template (info_TEXINFOS): Remove unused vari

Re: GNU make to consider files checksum

> From: Giuseppe Scrivano <[EMAIL PROTECTED]> > Date: Fri, 11 Apr 2008 23:45:02 +0200 > > Other systems like scons already support this feature and it would be > great to have it for GNU Make too. > > I attached a patch against the current CVS to add --use-checksum to > GNU Make, it is just a pro

Re: make version

> Date: Thu, 17 Apr 2008 16:51:47 +0100 > From: ying <[EMAIL PROTECTED]> > > Sorry to bother you. When I installed the mingw and msys the current > make version is 3.79.1. I tried to install the make 3.80 and cover the > previous min-make file. Unfortunately no matter what I did the version > i

Re: make-3.81: bug-report: function abspath works incorrectly on widows

> Date: Wed, 25 Jun 2008 20:19:39 +0400 > From: "Vitaly Murashev" <[EMAIL PROTECTED]> > > I found a bug in GNU Make 3.81 on MS Windows. So let me discuss it and > suggest a patch. Thanks. Your code is generally OK, but, unless I'm missing something, it has a few deficiencies: . It doesn't add

Re: make-3.81: bug-report: function abspath works incorrectly on widows

> Date: Thu, 26 Jun 2008 14:44:38 +0400 > From: "Vitaly Murashev" <[EMAIL PROTECTED]> > Cc: bug-make@gnu.org > > > . It doesn't add an explicit drive letter to file names such as > >"/foo/bar", and generally treats such names incorrectly. > > You are right, and i suppose that the best way is

Re: Reimplementing DJGPP support for make.

> From: Juan Manuel Guerrero <[EMAIL PROTECTED]> > Date: Mon, 30 Jun 2008 10:12:24 +0200 > > A couple of months ago I presented a patch to implement DJGPP/MSDOS support > in make again. Now that the legal paperwork has been signed and submitted > I resent an improved patch again. The patch is ba

Re: BATCH_MODE_ONLY_SHELL configuration fails with unixy shells

> From: "Russo, David" <[EMAIL PROTECTED]> > Date: Mon, 29 Sep 2008 14:21:59 -0500 > > There seems to be a bug in make 3.81 when make is configured with > BATCH_MODE_ONLY_SHELL enabled. The problem only occurs when > BATCH_MODE_ONLY_SHELL is enabled, make determines the shell is "unixy", and a

Re: Fw: error 127

> Date: Sat, 11 Oct 2008 02:03:27 -0700 (PDT) > From: Uygar UZUNHASAN <[EMAIL PROTECTED]> > > g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_SQL_LIB > -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED > -I/usr/qt/4/mkspecs/linux-g++ -I. -I/usr/qt/4/include/QtCore > -I/usr/qt/4/

Re: bug

> Date: Tue, 14 Oct 2008 11:45:43 +0800 > From: =?gb2312?B?Q2Fzc2llIFh1KNDsytjIQSkoQkop?= <[EMAIL PROTECTED]> > > This program built for i686-pc-mingw32 > > Report bugs to > > make[1]: *** [stfdma.lib] Error 2 > > make[1]: Leaving directory `D:/SW/5105_5107SingFTABETA3_rc_test/src/objs/ST20'

[bug #20495] debug version crashes on windows on close(-1)

Follow-up Comment #2, bug #20495 (project make): Thank you for your report. I fixed this bug in CVS with the attached patch. ___ Reply to this item at: ___

[bug #20495] debug version crashes on windows on close(-1)

Additional Item Attachment, bug #20495 (project make): File name: w32clospipe.difSize:0 KB ___ Reply to this item at: ___ Message sent

[bug #17277] Pathes longer than 128 Chars fail with make under windows

Follow-up Comment #2, bug #17277 (project make): Fixed with the attached patch (which also fixes bug #25662). (file #17686) ___ Additional Item Attachment: File name: w32searchpath.dif Size:5 KB ___

[bug #17277] Pathes longer than 128 Chars fail with make under windows

Update of bug #17277 (project make): Status:None => Fixed ___ Reply to this item at: ___ Messa

[bug #25662] PATH (sometimes) not set when set from target-variable

Follow-up Comment #1, bug #25662 (project make): Fixed with the attached patch (which also fixes bug #17277). ___ Reply to this item at: ___ Message s

[bug #25662] PATH (sometimes) not set when set from target-variable

Update of bug #25662 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => CVS ___

[bug #25662] PATH (sometimes) not set when set from target-variable

Update of bug #25662 (project make): Open/Closed: Closed => Open ___ Reply to this item at: ___ Messa

[bug #25662] PATH (sometimes) not set when set from target-variable

Additional Item Attachment, bug #25662 (project make): File name: w32searchpath.dif Size:5 KB ___ Reply to this item at: ___ Message sent

[bug #25662] PATH (sometimes) not set when set from target-variable

Update of bug #25662 (project make): Open/Closed:Open => Closed ___ Reply to this item at: ___ Messa

[bug #25412] mingw32-make crashes when double quotes at end of PATH

Follow-up Comment #1, bug #25412 (project make): Fixed with the attached patch. ___ Reply to this item at: ___ Message sent via/by Savannah http://s

[bug #25412] mingw32-make crashes when double quotes at end of PATH

Additional Item Attachment, bug #25412 (project make): File name: qpathw32_2.dif Size:1 KB ___ Reply to this item at: ___ Message sent

[bug #25412] mingw32-make crashes when double quotes at end of PATH

Update of bug #25412 (project make): Status:None => Fixed Fixed Release:None => CVS ___ Reply to this item at:

[bug #25412] mingw32-make crashes when double quotes at end of PATH

Update of bug #25412 (project make): Open/Closed:Open => Closed ___ Reply to this item at: ___ Messa

Re: Windows paths with make 3.81

> Date: Mon, 23 Mar 2009 13:44:31 +0300 > From: "Alexander V. Trushkin" > > In spite of that the upper directory in Windows contains files of the > kind ..\*.x, the construction of the type: > > $(wildcard ..\*.x) > > returns an empty list as well as > > a : ..\*.x > > does not find

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

> From: Peter Halliday > Date: Fri, 03 Apr 2009 13:28:36 + > Cc: > > I think I have a fix for this issue (at least it's working for me with my > makefiles). I have edited dir.c to limit the maximum number of open > directories under windows to just 1 (normally it is 10) this results in > dir

Re: Error 127

> Date: Wed, 6 May 2009 14:32:28 -0300 > From: Julio Cesar Perroni > > Hi. I did this command and returned this error. Please, answer me what to > do. Thanks. > > [r...@localhost mpfr-2.4.1]# make install > Making install in tests > make[1]: Entrando no diretório `/home/jc/Área de Trabalho/mpfr-

Re: build failed

> Date: Mon, 11 May 2009 14:40:18 +0200 > From: STAGEMRD STAEMRD > > hi, i'm working with avr rz200. > when i program my kit with software bitcloud i have a error on build. > the error is: > Build started 11.5.2009 at 14:33:36 > make all -C > make: option requires an argument -- C I suspect that

Re: there were some bugs when i installed EGSnrc

> From: =?gb2312?B?x9i9ow==?= > Date: Thu, 21 May 2009 10:29:48 +0800 > > ===> Compiling Mortran3 ... > > process_begin: CreateProcess((null), echo Compiling mortran3.f > C:\HEN_HOUSE\lib\gnu_win32\machine.f, ...) failed. Can you show the Makefile that produced these error messages? Also, wha

Re: there were some bugs when i installed EGSnrc

> From: =?gb2312?B?x9i9ow==?= > Date: Fri, 22 May 2009 09:42:24 +0800 > > My make and gcc version: > > GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. > gcc version 3.4.2 (mingw-special) Make 3.79.1 is quite old, and it had bugs in the Windows port. Please download and install

Re: Bug with double slashes

> From: Paul Smith > Date: Sat, 06 Jun 2009 02:01:03 -0400 > Cc: bug-make@gnu.org > Reply-To: psm...@gnu.org > > Less obvious is which of the various ways it could be fixed is the right > way. Should we stop "cleaning" these paths altogether, to work around > the bug in glibc glob()? I think if

[bug #26888] SHELL as target variable ignored

Follow-up Comment #1, bug #26888 (project make): TRy cmd.exe and sh.exe, and you will see that SHELL is NOT ignored... ___ Reply to this item at: ___

[bug #26888] SHELL as target variable ignored

Follow-up Comment #3, bug #26888 (project make): It's not a bug, strictly speaking: SHELL should only be set to a command that supports a "-c ARGUMENT" invocation. CMD.EXE does not, so you invoke it as "cmd.exe -c SOMETHING" whereas it expects "cmd.exe /c SOMETHING" (and in addition the quoting

[bug #26888] SHELL as target variable ignored

Update of bug #26888 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Reply to this item at:

[bug #26891] make enters interactive shell

Update of bug #26891 (project make): Assigned to:None => eliz ___ Follow-up Comment #1: It's not a bug, strictly speaking: SHELL should only be set to a command that supports a "-c ARGUM

[bug #26915] SHELL has no effect

Update of bug #26915 (project make): Status:None => Duplicate ___ Follow-up Comment #1: This is a duplicate of bug #26888. ___

[bug #26915] SHELL has no effect

Update of bug #26915 (project make): Open/Closed:Open => Closed ___ Reply to this item at: ___ Messa

[bug #26921] line 0: unexpected EOF while looking for matching `"'

Update of bug #26921 (project make): Status:None => Works for me ___ Follow-up Comment #1: It works for me. I suspect it's a problem with the port of sh you are using. Please either try a

[bug #26886] abspath returns garbage

Update of bug #26886 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => CVS

Re: Evading the command line length limit (on Linux)

> From: Paul Smith > Date: Thu, 30 Jul 2009 10:19:53 -0400 > Cc: Xan Lopez , bug-make@gnu.org > > Remember that we actually have this problem in spades on other systems, > like Windows, where the command line length if far SHORTER than Linux. Perhaps you think about the 127-character limitation

Re: [psm...@gnu.org: GNU make: Next release schedule.]

> From: Juan Manuel Guerrero > Date: Fri, 18 Sep 2009 00:20:00 +0200 > Cc: Eli Zaretskii , > djgpp-work...@delorie.com > > This patch contains the changes required to compile and run the testsuite > using DJGPP. It is basicaly the same that I have submitted almost two

Re: [psm...@gnu.org: GNU make: Next release schedule.]

> From: Paul Smith > Cc: Juan Manuel Guerrero , djgpp-work...@delorie.com, > bug-make@gnu.org > Date: Sun, 27 Sep 2009 12:47:29 -0400 > > Maybe we should just accept that we're going to have to do work to merge > again from upstream, and make the changes we need to make locally. Fine wit

Re: [psm...@gnu.org: GNU make: Next release schedule.]

> From: Paul Smith > Cc: juan.guerr...@gmx.de, djgpp-work...@delorie.com, bug-make@gnu.org > Date: Sun, 27 Sep 2009 14:55:40 -0400 > > On Sun, 2009-09-27 at 19:03 +0200, Eli Zaretskii wrote: > > Let me know if it's okay to install the patch for gl

[bug #27590] MSVC Win64 build patch

Follow-up Comment #1, bug #27590 (project make): Can you please give a short explanation for each change? Also, are you sure the first of these changes doesn't harm the Win32 build in any way? (I don't have MSVC installed to try this myself.) Thanks. _

[bug #27809] several win64 fixes

Follow-up Comment #1, bug #27809 (project make): Thank you for your contribution. I have a few questions for the patches you sent: 1. What versions of GCC and of MinGW runtime did you use to build Make? 2. Which header defines pid_t as appropriate for both 32-bit and 64-bit Windows? What is t

Re: [bug #27809] several win64 fixes

> From: Ozkan Sezer > Date: Mon, 26 Oct 2009 19:20:27 + > > > > 3. Why did you need casts in assignments, like this: > > > > -*pid_p = (int) hProcess; > > +*pid_p = (pid_t) hProcess; > > > > Because you are casting a handle, which is a ptr*, to an int. But you change pid_p to poin

Re: [bug #27809] several win64 fixes

> From: Ozkan Sezer > Date: Mon, 26 Oct 2009 20:27:27 + > > > -mthreads : This one is a noop for mingw-w64 crt. This is needed to properly handle Ctrl-C, since (at least on w32) the signal handler runs in a separate thread. So what happens in a w64 build of Make if you press Ctrl-C while

Re: bug with Windows interface: echo. in command only works when redirected

t; > makefile: > - > SHELL=cmd.exe > foobar: > @echo. > > > gives: > > C:\tmp>make foobar > process_begin: CreateProcess(NULL, echo., ...) failed. > make (e=2): The system cannot find the file spec

[bug #28126] bug with Windows interface: echo. in command only works when redirected

Update of bug #28126 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => CVS

[bug #28126] bug with Windows interface: echo. in command only works when redirected

Follow-up Comment #3, bug #28126 (project make): I omitted those commands on purpose: they are executable programs on some older Windows versions, not shell built-ins. But if you, or someone else, can present a real-life use-case where it is good to have them as built-ins, I will consider changi

[bug #28126] bug with Windows interface: echo. in command only works when redirected

Follow-up Comment #5, bug #28126 (project make): Well, at least there is some progress after 3 and a half years... ___ Reply to this item at: ___ Mess

Re: Crashing when using make with option -j.

> Date: Thu, 18 Mar 2010 16:26:19 -0700 > From: tom honermann > Cc: bug-make@gnu.org > > > On 3/18/2010 2:22 PM, Thiago C. Santini wrote: > > Yeah, that was my first thought when using -j, 8 processors each one > > with hyper-threading should be optimized with 16 jobs but when testing > > it I

[bug #29245] Bug with DOS Path in Secondary Expansion (with Fix)

Follow-up Comment #1, bug #29245 (project make): Sorry, but I don't like this solution. A comma is a legitimate file-name character on Windows, used, e.g., in RCS files. Using it as a delimiter here will cause Make to misdiagnose other syntax errors. For example, just remove the $(call) from t

[bug #29244] MSVC Compatibility broken with main.c Revision 1.237 (with Proposal for Fix)

Follow-up Comment #1, bug #29244 (project make): Paul, can you comment on this? The ChangeLog does not mention this change to main.c, so there's no reason given to this change that I could use for reasoning about this change. By the way, the issue with MSVC is probably related to string concate

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

Follow-up Comment #1, bug #30323 (project make): According to this page: http://winapi.freetechsecrets.com/win32/WIN32GetModuleFileName.htm GetModuleFileName is available on Windows 9X as well. (I believe the above site more than I believe the official MS docs, because some time ago they simpl

Re: [bug #27809] several win64 fixes

> From: "Paul D. Smith" > Date: Mon, 05 Jul 2010 18:32:15 + > > > Follow-up Comment #9, bug #27809 (project make): > > I've applied most of the second patch. The first patch is mostly in the w32 > area so maybe Eli is a better person to review it? I will try to do that over the next few d

Re: GNU make 3.81.90 prerelease available

a, because there's no way we can guess the right way of declaring it. What was the motivation for David's request? I suggest the following patch, which should DTRT on GNU/Linux and on other platforms alike: 2010-07-09 Eli Zaretskii * make.h (alloca) [!__GNUC__]: Don'

Re: [bug #27809] several win64 fixes

> Date: Mon, 05 Jul 2010 21:42:52 +0300 > From: Eli Zaretskii > Cc: seze...@gmail.com, bo...@kolpackov.net, bug-make@gnu.org > > > From: "Paul D. Smith" > > Date: Mon, 05 Jul 2010 18:32:15 + > > > > > > Follow-up Comment #9, bug #278

Re: [bug #27809] several win64 fixes

> Date: Fri, 9 Jul 2010 13:18:12 +0300 > From: Ozkan Sezer > Cc: bug-make@gnu.org, bo...@kolpackov.net > > On Fri, Jul 9, 2010 at 1:17 PM, Ozkan Sezer wrote: > > On Fri, Jul 9, 2010 at 1:00 PM, Eli Zaretskii wrote: > >>> Date: Mon, 05 Jul 2010 21:42:52 +0300 &g

Re: [bug #27809] several win64 fixes

> From: Ozkan Sezer > Date: Mon, 05 Jul 2010 19:58:04 + > > > Follow-up Comment #11, bug #27809 (project make): > > On Mon, Jul 5, 2010 at 9:42 PM, Eli Zaretskii wrote: > >> From: "Paul D. Smith" > >> Date: Mon, 05 Jul 2010 18:32:15 +000

[bug #27809] several win64 fixes

Update of bug #27809 (project make): Fixed Release:None => CVS ___ Follow-up Comment #13: Fixed in CVS, usind mots of the last patch. ___

[bug #27825] win64 fix for config.h.W32.template

Update of bug #27825 (project make): Fixed Release:None => CVS ___ Follow-up Comment #4: Fixed as part of bug #27809. ___ Reply

[bug #30312] $(abspath ...) fails with Windows UNC path (with fix)

Update of bug #30312 (project make): Fixed Release:None => CVS ___ Follow-up Comment #1: I committed a slightly different fix for this problem. Thanks.

[bug #30312] $(abspath ...) fails with Windows UNC path (with fix)

Update of bug #30312 (project make): Open/Closed:Open => Closed ___ Reply to this item at: ___ Messa

[bug #27809] several win64 fixes

Update of bug #27809 (project make): Open/Closed:Open => Closed ___ Reply to this item at: ___ Messa

Re: [bug #27809] several win64 fixes

> Date: Fri, 9 Jul 2010 14:45:03 +0300 > From: Ozkan Sezer > Cc: psm...@gnu.org, bo...@kolpackov.net, bug-make@gnu.org > > On Fri, Jul 9, 2010 at 2:14 PM, Eli Zaretskii wrote: > >> From: Ozkan Sezer > >> Date: Mon, 05 Jul 2010 19:58:04 + > >> &

Re: [bug #27809] several win64 fixes

> Date: Fri, 9 Jul 2010 15:30:09 +0300 > From: Ozkan Sezer > Cc: psm...@gnu.org, bo...@kolpackov.net, bug-make@gnu.org > > In make.h, the w32_kill prototpe sitll needs updating, though, like: > > -int w32_kill (int pid, int sig); > +int w32_kill (pid_t pid, int sig); I'm holding off make.h modi

Re: GNU make 3.81.90 prerelease available

Ping! > Date: Fri, 09 Jul 2010 12:06:09 +0300 > From: Eli Zaretskii > Cc: bug-make@gnu.org > > > From: Paul Smith > > Date: Wed, 07 Jul 2010 01:55:49 -0400 > > > > The first prerelease of the next version of GNU make is available on

Re: GNU make 3.81.90 prerelease available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 12 Jul 2010 09:19:42 -0400 > > On Mon, 2010-07-12 at 10:20 +0300, Eli Zaretskii wrote: > > > This change: > > > > > > 2009-10-03 Paul Smith > > > > > > * make.h: In

[bug #17381] Compile errors under DJGPP

Update of bug #17381 (project make): Open/Closed:Open => Closed Operating System: MS Windows => MS-DOS ___ Follow-up Comment #3: The MS-DOS build does

  1   2   3   4   5   6   7   8   9   >