:26
To: bug-make
Subject: Maybe a bug in make manual.
https://www.gnu.org/software/make/manual/make.html#Overriding-Makefiles
* EXTERNAL EMAIL *
https://www.gnu.org/software/make/manual/make.html#Overriding-Makefiles<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
https://www.gnu.org/software/make/manual/make.html#Overriding-Makefiles
The last 2 paragraph of chapter [3.5 How Makefiles are Remade ]
Original Manul
However, on occasion you might actually wish to prevent updating of even the
makefiles. You can do this by specifying the make
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
Hello,
Why "Grouped targets recipe"in the following Makefile
targets = target1 target2
all : $(targets)
$(targets) &:
@echo "Grouped targets recipe"
@echo $@ > target1
@echo $@ > target2
clean :
rm -rf $(targets)
runs one time using command 'make' and two times using command '
> 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.
Dear Developers,
I found a typo in output.c in make 4.0.
Please see an attached make40-msvc.diff.
Best regards,
Akira Kakuto
make40-msvc.diff
Description: Binary data
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/b
Dear GNU make maintainers,
I've found a use case in which a chain of prerequisite targets appears to
ignore the private modifier on a pattern specific variable definition. This
occurs in gnu make 3.82. Please find a simple example of this use case below.
This seems like a bug, can someone pleas
Hi,
I'm installing make-3.82 from source into my home directory (don't
ask) on a CentOS 5.6 system, and I'm using this command to do it:
configure --prefix=`echo ~`
Configure then does its thing, and at the end says:
...
checking if malloc debugging is wanted... no
configure: creating ./conf
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
I am using the following version:
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):
.SECONDEXPANSION:
main_OBJS := main.o try.o test.o
lib_OBJS := lib.o api.o
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
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:
I have a very convoluted makefile that triggers what I believe to be a bug in
make-3.81. I have looked through th
On Thu, Mar 09, 2006 at 06:19:37PM -0500, Paul D. Smith wrote:
>%% Bernhard Fischer <[EMAIL PROTECTED]> writes:
>It almost seems like we need to move the stem from being a per-target
>value to being a per-prerequisite value, since it can change depending
>on which prerequisites are being expanded.
Hi,
busybox is triggering a bug in make-3.81rc1. This bug is at least also
existing in make-3.81beta4 (from debian).
current busybox-svn does provoke this with make-3.81beta4, 3.81rc1 and
cvs-HEAD:
make: *** No rule to make target
`/scratch/src/busybox/e2fsprogs/blkid/blkid/blkid_getsize.c
Bernhard Fischer wrote:
Hi,
busybox is triggering a bug in make-3.81rc1. This bug is at least also
existing in make-3.81beta4 (from debian).
Is this a real bug or a user error?
I am leaning towards the real bug. I can't fault anything in the
Makefile you provided, and the failing pa
%% Bernhard Fischer <[EMAIL PROTECTED]> writes:
bf> busybox is triggering a bug in make-3.81rc1. This bug is at least also
bf> existing in make-3.81beta4 (from debian).
bf> current busybox-svn does provoke this with make-3.81beta4, 3.81rc1 and
bf> cvs-HEAD:
bf>
santhosh km <[EMAIL PROTECTED]> writes:
> x:
> ccsimpc -o HELLO_WORLD helloWorld.o
^^
___
Bug-make mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/
Hi,
I am trying porting of c files to VxWorks thru cygwin
using the GNU-Make Version 3.80 .
I have a problem while using makefile. The problem is
the commond:
"ccsimpc -o HELLO_WORLD helloWorld.c"
works on the command line and I get the HELLO_WORLD
executable file.
But doesn't work thru m
are being parsed as ':'s for additional target patterns. Is
> ja> this a bug in make 3.80 or make 3.81?
>
> ja> What is the expected behaviour?
>
> You'll need to follow up on the make-w32 mailing list for this. There
> have been a number of changes to the W
%% Jamie Allsop <[EMAIL PROTECTED]> writes:
ja> (Windows 2k/XP(tested on both), Cygwin, make 3.80 and make 3.81 beta)
ja> This suggests to me that the ':' in the path names for the windows
ja> drives are being parsed as ':'s for additional target pattern
[snip]
$(PROJECT) : $(OBJFILES)
$(LINKER_DIRECTIVE)
Should read:
$(PROJECT) : $(OBJFILES)
$(LINKER_DIRECTIVE)
$(OBJFILES) : %.obj : %.cpp
$(COMPILER_DIRECTIVE)
$(OBJFILES) : %.obj : %.cpp
$(COMPILER_DIRECTIVE)
[snip]
Jamie
___
Bug-make ma
3.80 and make 3.81 without a problem.
This suggests to me that the ':' in the path names for the windows
drives are being parsed as ':'s for additional target patterns. Is this
a bug in make 3.80 or make 3.81?
What is the expected behaviour?
Thanks
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
Hello,
I believe there is a bug in 3.79.1. It occurs late in function
try_variable_definition, where the code
v->append = append;
is executed. For a build with WINDOWS32 defined the struct v was not
initialized in some cases (specifically, when processing a line of the
form SHELL = /bin/bas
Scripsit "Paul D. Smith" <[EMAIL PROTECTED]>
> %% Henning Makholm <[EMAIL PROTECTED]> writes:
> hm> By the way, it is not *every* make that behaves this way. At least
> hm> /usr/ccs/bin/make on SunOS 5.7 doesn't.
> Yes it does.
Mea culpa - apparently I didn't think too well during the exper
Hi,
I ran across a bug during the configure/build phase of Make
3.79.1. I'm not sure if the bug is part of the Make code
itself or something inherited from Autoconf/Automake, but
here it is.
I'm building Make on HP-UX 11.00 with GCC. I've done this
in the past without problem, but I just upgrad
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.
--
-
One of our users brought this problem to my attention. The problem
occurs on linux (RedHat 6.2) but not on solaris. I have not tried
any other architectures. Nor does it exist in 3.78.1.
==
bartelt@noric05 $ uname -a
%% [EMAIL PROTECTED] (Jimi X) writes:
>> "PDS" == Paul D Smith <[EMAIL PROTECTED]> writes:
PDS> Thanks; this has been fixed in the sources for a while.
jx> Sorry 'bout that.. is that on sourceware?
No. GNU tools are available via CVS on the FSF's subversions server.
Start here:
h
> "PDS" == Paul D Smith <[EMAIL PROTECTED]> writes:
PDS> Thanks; this has been fixed in the sources for a while.
Sorry 'bout that.. is that on sourceware?
PDS> There are certain tests that configure must run which won't work
PDS> in a cross-compiled environment, because they require actua
%% [EMAIL PROTECTED] (Jimi X) writes:
jx> make-3.79.1/configure[3172]: (cross-compiling): unknown test operator
jx> corresponding line # 99 in configure.in
jx> if test $ac_cv_func_gettimeofday = yes; then
jx> $ac_cv_func_gettimeofday and be empty making the test fail.
jx> need to wra
make-3.79.1/configure[3172]: (cross-compiling): unknown test operator
corresponding line # 99 in configure.in
if test $ac_cv_func_gettimeofday = yes; then
$ac_cv_func_gettimeofday and be empty making the test fail.
need to wrap the variable in quotes
-Jimi X
BTW: since when can you not build
This is already fixed. You need the latest version of GNU make (3.79.1).
HTH.
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://www.paulandlesl
Hello,
I believe I have found a bug in version 3.79 of gmake.
I ftp'd the src files from the ftp mirror site at
ftp://sunsite.utk.edu/pub/gnu/ftp/
I have attached a small gzipped tarfile which illustrates
the problem. you should be able to cd into the lib/
directory and just type "make".
I
%% 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 b
Hi
I found bug in make-3.79.1 (it accurs also in 3.78.1).
If a Makefile includes another file (Makefile.included) and if
the included file defines prerequisites for a target (or both
define prerequisites), then the prerequisites defined in the
included files a silently ignored.
I wrote a
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!
--
-
There is a bug in make-3.79 which was not present in 3.77. I have
confirmed the problem under IRIX 6.5 and SunOS 5.5.1, but I believe it
affects all OSes supporting archives.
When using implicit rules for library archiving, the timestamp is computed
incorrectly for the (not yet existing) target
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.
--
Hello,
using make 3.79 on my Solaris 2.7 system I get a problem with
dependencies of ar-elements.
There seems to be something wrong with the times retrieved from ar:
gmake depend=true targets
gmake[1]: Entering directory `/home/strasser/cve/src/libraries/utils'
/sw/local/bin/gcc -V2.95.1 -Wpointe
%% [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
Hi
Downloaded and compiled make 3.79 from the canadian mirror
today. I am using Microsoft VC 6.0 and am compiling for windows.
The variable debug_flag is declared in main.c as:
static int debug_flag = 0;
And is referenced in sub_proc.c as
extern int debug_flag; /* Declared in main.c */
Obv
47 matches
Mail list logo
