On Tue, 2020-02-18 at 23:00 +0300, Alexander Khomyak wrote:
> Why "Grouped targets recipe"in the following Makefile
>
> targets = target1 target2
>
> all : $(targets)
>
> $(targets) &:
> @echo "Grouped targets recipe"
> @echo $@ > target1
> @echo $@ > target2
>
> clean :
> rm -r
On Fri, 2010-06-18 at 15:07 -0600, kevin_harrel...@agilent.com wrote:
> GNU Make 3.80
> This program built for x86_64-redhat-linux-gnu
>
> I am trying to get secondary expansion to work. Here is the source
> (straight from the on-line manual, so it SHOULD work):
Nope, because the on-line manual
ces+mdorey=bluearc@gnu.org] On Behalf Of David
Wuertele
Sent: Tuesday, January 20, 2009 15:07
To: bug-make@gnu.org
Subject: Re: Bug in make-3.81: variable_buffer moves out from under
buffer
Martin Dorey bluearc.com> writes:
> In the original makefile, does
> the long rule really not co
Martin Dorey bluearc.com> writes:
> In the original makefile, does
> the long rule really not contain any variables or involve any $(eval)
> trickery?
Not sure what you mean by trickery, but it definitely involves eval and
variables.
The rule is created with an eval:
$(eval $(call somemacro,m
, 2009 13:44
To: bug-make@gnu.org
Subject: Re: Bug in make-3.81: variable_buffer moves out from under
buffer
Martin Dorey bluearc.com> writes:
> And it looks like there are several other instances of it too.
That's what I was afraid of. I looked at the other places where
xreallo
Martin Dorey bluearc.com> writes:
> And it looks like there are several other instances of it too.
That's what I was afraid of. I looked at the other places where xrealloc
could get called, but I couldn't find any that referenced the original buffer
address after the xrealloc. I suspected that
mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Paul
Smith
Sent: Tuesday, January 20, 2009 11:16
To: David Wuertele
Cc: bug-make@gnu.org
Subject: Re: Bug in make-3.81: variable_buffer moves out from under
buffer
On Tue, 2009-01-20 at 18:53 +, David Wuertele wrote:
> I
On Tue, 2009-01-20 at 18:53 +, David Wuertele wrote:
> I posted this to the developer list but got no response. Looks like there's
> been no activity on that list since October. Is it dead? Anyway, here's the
> bug report:
Which list do you mean by the developer list? It's helpful if you
santhosh km <[EMAIL PROTECTED]> writes:
> x:
> ccsimpc -o HELLO_WORLD helloWorld.o
^^
___
Bug-make mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/
Hi; this bug has been reported before and is fixed in the CVS version of
GNU make; the fix will be in the next release.
Thanks for the report!
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips a
I think this is a locale problem. GNU make 3.79.1 uses the standard
libc globbing library, which obeys the sorting order in the locale.
Make sure your locale (LC_ALL and/or LANG) is set to "C", or at least
your sort order (LC_COLLATE) is set that way, and not to en_US or
whatever.
--
-
%% Jochen Hepp <[EMAIL PROTECTED]> writes:
jh> I found bug in make-3.79.1 (it accurs also in 3.78.1).
This is a bug in your makefile.
jh> If a Makefile includes another file (Makefile.included) and if the
jh> included file defines prerequisites for a target (or both define
jh> prerequis
This is PR/1696 in the GNU make bug database. A patch is included in
the resolution (essentially the same fix you used).
You can find info on accessing the GNU make bug database in the README
in the GNU make distribution.
Thanks for the report!
--
-
This is an instance of make PR/1696; see the bug report for a patch.
http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1696
I will be releasing a minor update of GNU make fairly shortly to address
this and a couple of other problems.
HTH.
--
%% [EMAIL PROTECTED] writes:
j> extern int debug_flag; /* Declared in main.c */
j> Obviously, you get a link error.
I replaced this with a reference to the new DB macro.
j> Also, LOCALEDIR is not declared anywhere when using win 32.
j> This causes a compile error. I just put
j> #d
15 matches
Mail list logo