Date: Wed, 6 May 2009 14:32:28 -0300
From: Julio Cesar Perroni jcperr...@gmail.com
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
Date: Mon, 11 May 2009 14:40:18 +0200
From: STAGEMRD STAEMRD stage...@gmail.com
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
From: =?gb2312?B?x9i9ow==?= qinjiansw...@hotmail.com
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
From: =?gb2312?B?x9i9ow==?= qinjiansw...@hotmail.com
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
From: Paul Smith psm...@gnu.org
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
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:
http://savannah.gnu.org/bugs/?26888
___
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 in
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
Update of bug #26915 (project make):
Status:None = Duplicate
___
Follow-up Comment #1:
This is a duplicate of bug #26888.
___
Update of bug #26915 (project make):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?26915
___
Message
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
Update of bug #26886 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = CVS
From: Paul Smith psm...@gnu.org
Cc: Juan Manuel Guerrero juan.guerr...@gmx.de, 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
From: Paul Smith psm...@gnu.org
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 glob.c.
Go ahead.
Done
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.
From: Ozkan Sezer invalid.nore...@gnu.org
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
From: Ozkan Sezer invalid.nore...@gnu.org
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
Update of bug #28126 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = CVS
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
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:
http://savannah.gnu.org/bugs/?28126
___
Date: Thu, 18 Mar 2010 16:26:19 -0700
From: tom honermann tom.honerm...@oracle.com
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
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
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
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
From: Paul D. Smith invalid.nore...@gnu.org
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
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 e...@gnu.org
* make.h (alloca) [!__GNUC__]: Don't define prototype.
--- make.h~0
Date: Mon, 05 Jul 2010 21:42:52 +0300
From: Eli Zaretskii e...@gnu.org
Cc: seze...@gmail.com, bo...@kolpackov.net, bug-make@gnu.org
From: Paul D. Smith invalid.nore...@gnu.org
Date: Mon, 05 Jul 2010 18:32:15 +
Follow-up Comment #9, bug #27809 (project make):
I've applied
Date: Fri, 9 Jul 2010 13:18:12 +0300
From: Ozkan Sezer seze...@gmail.com
Cc: bug-make@gnu.org, bo...@kolpackov.net
On Fri, Jul 9, 2010 at 1:17 PM, Ozkan Sezer seze...@gmail.com wrote:
On Fri, Jul 9, 2010 at 1:00 PM, Eli Zaretskii e...@gnu.org wrote:
Date: Mon, 05 Jul 2010 21:42:52 +0300
Update of bug #27809 (project make):
Fixed Release:None = CVS
___
Follow-up Comment #13:
Fixed in CVS, usind mots of the last patch.
Update of bug #27825 (project make):
Fixed Release:None = CVS
___
Follow-up Comment #4:
Fixed as part of bug #27809.
___
Reply
Update of bug #30312 (project make):
Fixed Release:None = CVS
___
Follow-up Comment #1:
I committed a slightly different fix for this problem.
Thanks.
Update of bug #30312 (project make):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?30312
___
Message
Update of bug #27809 (project make):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27809
___
Message
Date: Fri, 9 Jul 2010 14:45:03 +0300
From: Ozkan Sezer seze...@gmail.com
Cc: psm...@gnu.org, bo...@kolpackov.net, bug-make@gnu.org
On Fri, Jul 9, 2010 at 2:14 PM, Eli Zaretskii e...@gnu.org wrote:
From: Ozkan Sezer invalid.nore...@gnu.org
Date: Mon, 05 Jul 2010 19:58:04 +
Date: Fri, 9 Jul 2010 15:30:09 +0300
From: Ozkan Sezer seze...@gmail.com
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
From: Paul Smith psm...@gnu.org
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 psm...@gnu.org
* make.h: Include alloca.h even on systems where __GNUC__
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
Follow-up Comment #4, bug #27590 (project make):
I don't care about the MSVC compiler, I use only GCC. Go ahead and commit
this, and if it breaks the GCC build, I will handle it in the next RC.
___
Reply to this item at:
From: Paul Smith psm...@gnu.org
Date: Tue, 20 Jul 2010 09:42:50 -0400
Cc: coordina...@translationproject.org
9d7a0f1fc1133d70f50f8b493912ba00
ftp://alpha.gnu.org/gnu/make/make-3.81.91.tar.bz2
62012451cee10ddf8be4b0be55cd5b36
ftp://alpha.gnu.org/gnu/make/make-3.81.91.tar.gz
This is
From: Paul Smith psm...@gnu.org
Date: Fri, 30 Jul 2010 01:26:46 -0400
Cc: bug-make@gnu.org
We have to ensure that these temporary files are cleaned up properly,
even in the face of users ^C'ing their make invocations. We also need
to verify that whatever methods we use will work properly
Date: Fri, 30 Jul 2010 17:08:55 +0800
From: Chiheng Xu chiheng...@gmail.com
Cc: psm...@gnu.org, bug-make@gnu.org
On Fri, Jul 30, 2010 at 4:53 PM, Eli Zaretskii e...@gnu.org wrote:
This is not to say that I think the original idea is easy to
implement.
Actually, it is not entirely
Date: Fri, 30 Jul 2010 12:10:36 +0100
From: Tim Murphy tnmur...@gmail.com
Cc: bug-make@gnu.org
gcc -o fred fred.cpp
perl makedef.pl -i something.def
perl prepdef.pl -i otherthing.def
error: fred.cpp: syntax error on line 345
ERROR: File not Found
Which file was missing? If you
From: Peter Lawrence peterl95...@sbcglobal.net
Date: Sat, 31 Jul 2010 07:41:49 -0700
Cc: bug-make@gnu.org
one thing I remember in detail about Sun's make, is that
instead of writing a level number
make[3]: ...
make[2]: ...
make[1]: ...
it wrote out the directory that
Date: Tue, 3 Aug 2010 07:51:22 +0100
From: Tim Murphy tnmur...@gmail.com
Cc: e...@opera.com, bug-make@gnu.org
mytarget:
-command1
-command2
-command3
Note that I'm using bash syntax here. On windows if you want to use
cmd.exe then good luck - I don't think it's really fit for
Update of bug #16362 (project make):
Status:None = Fixed
Assigned to:None = eliz
Open/Closed:Open = Closed
Fixed Release:
Update of bug #30662 (project make):
Status:None = Fixed
Assigned to:None = eliz
Open/Closed:Open = Closed
From: Juan Manuel Guerrero juan.guerr...@gmx.de
Date: Mon, 2 Aug 2010 20:24:58 +0200
Here is a small patch to make make compile out-of-the-box with djgpp.
Regards,
Juan M. Guerrero
2010-07-31 Juan Manuel Guerrero juan.guerr...@gmx.de
* configh.dos: Define
Follow-up Comment #1, bug #30714 (project make):
Unfortunately, the issue is a little bit more complicated: the MOVE command
is a built-in on some versions of Windows, but an external program move.exe on
others (Windows 9X). That (and not outdated information regarding the current
Windows
Follow-up Comment #6, bug #30714 (project make):
Savannah is not suited well for having a discussion. (Maybe we should start
a thread on make-...@gnu.org, if this is going to continue.) I respond to
some of the comments after quoting the relevant portion of it.
As for MOVE being external
Follow-up Comment #8, bug #30714 (project make):
Now imagine that somebody writes a recipe, thinking that it would be parsed
by shell (as documentation suggests). He creates for example a script named
foo.bat which is being called by the recipe. What he does not know is that
someone else created
From: Paul Smith psm...@gnu.org
Date: Tue, 31 Aug 2010 10:40:55 -0400
Cc: bug-make@gnu.org
Right, I didn't mean flock() or something; I just meant test for
existence. But, doing a loop waiting for a file to exist in a UNIX
shell vs. Windows command.com (for example) is not simple.
I
From: Paul Smith psm...@gnu.org
CC: mh...@suse.de, bug-make@gnu.org
Date: Tue, 31 Aug 2010 13:24:45 -0400
Too bad GNU's version of sleep, that accepts fractional seconds, is not
portable :-).
How about introducing a new Make function $(sleep) ? ;-)
From: Paul Smith psm...@gnu.org
Reply-To: psm...@gnu.org
CC: mh...@suse.de, bug-make@gnu.org
Date: Tue, 31 Aug 2010 16:57:16 -0400
A sub-make could sleep, no?
What I'm saying is that if you have a rule like this:
foo:
$(sleep 0.10) echo hi
The recipe is always
From: Alexander Kornilov alexander.korni...@teleca.com
Date: Tue, 28 Sep 2010 13:54:42 +0400
While I working on my build system I find some bugs in working of make
tool.
Could you, please, review issues?
Thanks for the reports. I will respond to the Windows-specific
issues.
Description:
From: Paul Smith psm...@gnu.org
Date: Tue, 28 Sep 2010 09:05:20 -0400
Cc: bug-make@gnu.org
However, your makefile is wrong and that's why it's failing for you in
GNU make 3.81. I have no idea why it works in Windows; if it does
that's a bug in the Windows version of make, IMO.
I'm
Follow-up Comment #2, bug #31361 (project make):
Pass the -v option to gcc (or g++ or cc1plus) to have it provide more
information.
But this is no longer a Make issue...
___
Reply to this item at:
http://savannah.gnu.org/bugs/?31361
Date: Thu, 21 Oct 2010 15:04:20 -0400
From: Mike Shal mar...@gmail.com
Cc: Bug-make@gnu.org
I don't see why Michael's example should fail, but I can reproduce the
behavior with 3.81 and 3.82.
It fails because, depending on the timing, app1.o may or may not exist
when Make comes to check
Update of bug #31490 (project make):
Item Group: Bug = Build/Install
Status:None = Wont Fix
Open/Closed:Open = Closed
From: jida...@jidanni.org
Date: Thu, 02 Dec 2010 10:13:31 +0800
Cc: bug-make@gnu.org
PS == Paul Smith psm...@gnu.org writes:
PS Make already uses high-resolution timestamps for comparison
PS automatically on filesystems that support it, if that's what you
PS mean.
That's the
From: Paul Smith psm...@gnu.org
Date: Fri, 07 Jan 2011 21:58:53 -0500
Cc: bug-make@gnu.org
I realize that maybe this doesn't matter on Windows where the filesystem
is not case-sensitive, but of course on Linux if you delete hello.c
that won't have any impact on Hello.c which is why Hello.c
Date: Sat, 8 Jan 2011 11:40:23 -0500
From: Hsu, ShihchiehIAS shihchieh@pw.utc.com
Cc: bug-make@gnu.org
Identical results are obtained as before. So the issue is probably not when
GNU/Linux renews the cache $(eval), but when Windows/Make refresh/update the
cache.
Maybe I
Date: Mon, 10 Jan 2011 08:03:31 -0500
From: Hsu, ShihchiehIAS shihchieh@pw.utc.com
Cc: bug-make@gnu.org
My friend tried the makefile file on Linux (make 3.81) with me watching, and
it works.
Thanks. I tried on GNU/Linux as well, when I first saw your report,
and it worked
From: Paul Smith psm...@gnu.org
CC: shihchieh@pw.utc.com, bug-make@gnu.org
Date: Mon, 10 Jan 2011 17:22:33 -0500
On Sat, 2011-01-08 at 11:35 +0200, Eli Zaretskii wrote:
But I wonder if this is really Windows-specific. Could this be the
example you asked for in Savannah bug#443
Date: Wed, 26 Jan 2011 21:34:25 +0100
From: Ralf Wildenhues ralf.wildenh...@gmx.de
You can write a conditional that tests @code{make} command flags such as
-@samp{-t} by using the variable @code{MAKEFLAGS} together with the
-@code{findstring} function
-(@pxref{Text Functions, , Functions
From: Paul Smith psm...@gnu.org
Date: Thu, 14 Apr 2011 13:29:09 -0400
On Thu, 2011-04-14 at 11:01 -0400, David Boyce wrote:
On Tue, Apr 12, 2011 at 1:46 PM, David Boyce david.s.bo...@gmail.com
wrote:
So I've made a proof-of-concept patch
against 3.82.90 which seems to work without
Date: Thu, 14 Apr 2011 14:12:16 -0400
From: David Boyce david.s.bo...@gmail.com
Cc: psm...@gnu.org, bug-make@gnu.org
On Thu, Apr 14, 2011 at 1:48 PM, Eli Zaretskii e...@gnu.org wrote:
David, can you explain why you needed to lock the files? Also, what
region(s) of the file you
Date: Thu, 14 Apr 2011 16:30:42 -0400
From: David Boyce david.s.bo...@gmail.com
Cc: Eli Zaretskii e...@gnu.org, bug-make@gnu.org
I don't know why this hasn't occurred to me or the authors of similar
programs before, but it appears to be possible to get a lock on any
writable file
Date: Fri, 15 Apr 2011 12:43:53 +0100
From: Tim Murphy tnmur...@gmail.com
Cc: David Boyce david.s.bo...@gmail.com, bug-make@gnu.org
I think it's an inevitable consequence that if you have a long-running
task then the output from it won't appear until it has completely
finished and you
Date: Fri, 15 Apr 2011 10:37:13 -0400
From: David Boyce david.s.bo...@gmail.com
Cc: psm...@gnu.org, bug-make@gnu.org
Finally, wouldn't it be a potential problem top inherit so many
handles to subordinate processes (2 for each running job)? We could
run out of available handles in
Date: Fri, 15 Apr 2011 12:39:56 -0400
From: David Boyce david.s.bo...@gmail.com
Cc: psm...@gnu.org, bug-make@gnu.org
On Fri, Apr 15, 2011 at 11:09 AM, Eli Zaretskii e...@gnu.org wrote:
But this new option uses up 2 additional files per job, doesn't it?
One or two, as discussed elsewhere
From: Paul Smith psm...@gnu.org
CC: David Boyce david.s.bo...@gmail.com, bug-make@gnu.org
Date: Fri, 15 Apr 2011 14:53:52 -0400
On Fri, 2011-04-15 at 19:54 +0300, Eli Zaretskii wrote:
What about the other issue: with the fact that output from a recipe is
only shown when the entire recipe
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Tue, 03 May 2011 01:33:38 -0400
But, I've been playing with a makefile that I have, that builds a
complete suite of GCC tools from scratch. I'm building them on larger
systems with -j5 or -j10 (not much compared to what some are
Date: Thu, 5 May 2011 22:30:04 +0100
From: Jon Grant j...@jguk.org
c:\make -f test.mk
unknown-exe
process_begin: CreateProcess(NULL, unknown-exe, ...) failed.
make (e=2): The system cannot find the file specified.
make: [build] Error 2 (ignored)
On GNU+Linux this looks like:
$
Date: Fri, 6 May 2011 21:01:24 +0100
From: Jon Grant j...@jguk.org
Cc: bug-make@gnu.org
Sorry, perhaps I was unclear. I am interested in the test.mk:5 text.
I don't mind the specific details or error code which is output later
in the line. Just the line number is my request.
Sorry for my
Update of bug #23922 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = CVS
Triage Status:
Date: Sun, 29 May 2011 21:45:38 -0700
From: Ben Robinson icareta...@gmail.com
I am submitting a patch which adds two new functions to GNU Make.
Thanks. Please wait for Paul's word about inclusion of these in
Make. What's below are a few comments based on a first impression
from the code.
From: itoken 110.keni...@gmail.com
Date: Mon, 6 Jun 2011 07:56:37 + (UTC)
Hi Eli-san,
Is this issue fixed in 3.82?
No, it isn't. The suggested patch looked dangerous to me, because it
would cause NULL to be passed process_init_fd, which would then use
it. I asked for an easily
From: Gururaj Bhat bs.g...@gmail.com
Date: Fri, 10 Jun 2011 10:18:02 +0530
I am getting the below error from *gmake*.
*_main: memory allocation error during startup*
when I try to run it in my Windows 7 build environment with cygwin.
Version of the gmake is 3.79
This is very old.
From: Gururaj Bhat bs.g...@gmail.com
Date: Fri, 10 Jun 2011 12:14:53 +0530
Ok.
Can you please point me where to download ( I mean link to get the latest
version)?
I searched on the net, but couldn't make out.
Here:
http://sourceforge.net/projects/mingw/files/MinGW/make/
Date: Fri, 10 Jun 2011 10:04:58 +0200
From: Johannes Lotz johannes.l...@rwth-aachen.de
just a short idea:
what about make love as a standard target - giving something like:
thanks. or sorry, for me there's no rule to make love. stop. :)
make love should yield not war, of course.
From: Gururaj Bhat bs.g...@gmail.com
Date: Fri, 10 Jun 2011 13:58:52 +0530
Thanks anyway that didn't fix my problem as you had mentioned :(
Will try something else out!
If you find a solution, please post it on bug-make or make-w32 mailing
lists. There was at least one other report about
Follow-up Comment #1, bug #34542 (project make):
I cannot reproduce this on my XP SP2 machine. I tried versions 3.80, 3.81,
and 3.82, and they all produce the expected output:
D:usrelidatatest3make
echo a/foo.c b/bar.c
a/foo.c b/bar.c
Perhaps you could run Make with the -d switch and see why
Date: Thu, 20 Oct 2011 20:19:33 +0200
From: Sebastian Pipping sebast...@pipping.org
I have some new code ready for you to tear apart, err review :-)
Here's mine:
+ /* Determine target file (i.e. stdout or stderr) and color to pick */
+ switch (type)
+{
+ case
Date: Fri, 21 Oct 2011 00:33:51 +0200
From: Sebastian Pipping sebast...@pipping.org
+ /* Determine target file (i.e. stdout or stderr) and color to pick */
+ switch (type)
+{
+ case OT_DIR_ENTER: target = stdout; color = color_dir_enter; break;
+ case
Follow-up Comment #2, bug #34530 (project make):
I wouldn't worry about this. Markus is on a crusade to eliminate the use of
`...' for many years. By contrast, in GNU projects it's a long-standing
tradition and at least a de-facto standard to use this kind of quoting,
because it's pure ASCII.
Follow-up Comment #3, bug #34832 (project make):
Thanks. I know what TLS means. I meant to ask why it is useful for
map_windows32_error_to_string to use thread local storage? What will that
gain for Make? The comment there said it was only needed for MSVC.
Follow-up Comment #5, bug #34832 (project make):
Which multiple threads in Make might try to access the same static buffer
concurrently? And under what circumstances? All but one call to
map_windows32_error_to_string in sub_proc.c are commented out.
Follow-up Comment #8, bug #34832 (project make):
Paul,
The Windows build of Make does use more than a single thread.
Ozkan,
Yes, I know that functions in the top-level directory call
map_windows32_error_to_string, but those functions all run in a single thread.
The only functions that don't
Follow-up Comment #13, bug #34832 (project make):
We could get rid of that static buffer, or we could use the __thread
declaration, but my point is: if we are enabling to produce error message
strings from several threads, we might as well actually do that and see that
it works, e.g., by
Follow-up Comment #18, bug #34832 (project make):
All the uses pointed out by Paul are from a single thread. The only problem,
if there is one, is with the calls from sub_proc.c.
As for TLS availability for MSVC being a proof that it works, I have my
doubts: with most of calls to the function
Follow-up Comment #21, bug #34832 (project make):
Ozkan,
I don't understand the emotions. This is supposed to be a technical
discussion. If I said something that sounded offensive, I apologize.
More to the point: I don't know why it is there. 1996 is way before I started
to be interested in
Date: Mon, 19 Dec 2011 18:41:47 +0800 (SGT)
From: Peter towlyhk-...@yahoo.com.hk
Reply-To: towlyhk-...@yahoo.com.hk
Suppose you don't know what the hyphen before each recipe command lines mean,
and want to search the manual for its meaning.
I suppose people will search these words
From: Paul Smith psm...@gnu.org
Date: Thu, 5 Jan 2012 15:20:07 -0500
Cc: bug-make@gnu.org
The other thing I wonder about is the hardcoding of ASCII colorized
strings and the start/stop character strings (\033[...). Are there
other methods of colorizing?
Yes.
Should we try to support
From: Paul Smith psm...@gnu.org
CC: Eli Zaretskii e...@gnu.org, bug-make@gnu.org
Date: Thu, 5 Jan 2012 17:32:50 -0500
On Thu, 2012-01-05 at 22:42 +0100, Sebastian Pipping wrote:
On 01/05/2012 09:46 PM, Eli Zaretskii wrote:
The easiest way of abstracting this is to have a function
Date: Thu, 05 Jan 2012 22:42:15 +0100
From: Sebastian Pipping sebast...@pipping.org
CC: psm...@gnu.org, bug-make@gnu.org
On 01/05/2012 09:46 PM, Eli Zaretskii wrote:
The easiest way of abstracting this is to have a function that turns
on a given color, and another function that turns off
From: Edward Welbourne e...@opera.com
Cc: psm...@gnu.org, make-...@gnu.org, bug-make@gnu.org
Date: Tue, 17 Jan 2012 17:08:02 +0100
How about moving them to a subdirectory, where they could bit-rot out
of sight?
In the presence of a version control system, even one as basic as CVS,
Update of bug #34832 (project make):
Open/Closed:Open = Closed
Fixed Release:None = CVS
___
Follow-up Comment #23:
I fixed this by
Update of bug #34832 (project make):
Status:None = Fixed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?34832
___
Message
Date: Sun, 12 Feb 2012 02:04:47 +0100
From: Sebastian Pipping sebast...@pipping.org
Cc: bug-make@gnu.org
with v5 [1] of the color patch we have moved into a situation where a
choice needs to be made:
- either we require/bundle/re-write CRT function vsnprintf or
- we sacrifice the
Date: Sun, 12 Feb 2012 18:11:49 +0100
From: Sebastian Pipping sebast...@pipping.org
CC: psm...@gnu.org, bug-make@gnu.org
Since we would run into buffer overflows with sprintf/vsprintf, we
rely on snprintf/vsnprintf for that task. Quoting from my man 3
printf output:
snprintf(),
101 - 200 of 733 matches
Mail list logo
