RE: debian:/usr/src/dahdi-linux-2.2.0.2#
kann mir da bitte jemand weiter helfen Leide nicht. Ihre Problem ist irgendwo anders - es gibt keine Bug mit make(1) hier. Vielleicht koennen sie Hilfe finden auf einen Mailing Liste oder Website fuer dahdi. (Wenn sie meinen schrecklichen Denglish verstehen koennen.) From: bug-make-bounces+mdorey=bluearc@gnu.org [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Alex Franzke Sent: Wednesday, September 09, 2009 08:04 To: bug-make@gnu.org Subject: debian:/usr/src/dahdi-linux-2.2.0.2# Hallo, habe eben erst ein Debian frisch installiert. Dann folgende schritte debian:~# aptitude install ssh debian:~# aptitude update debian:~# aptitude -y upgrade debian:~# aptitude -y install ntp ntpdate debian:~# aptitude -y install build-essential debian:~# aptitude -y install linux-headers-`uname -r` debian:~# cd /usr/src/ debian:/usr/src# wget http://downloads.digium.com/pub/libpri/libpri-1.4-current.tar.gz debian:/usr/src# tar xvzf libpri-1.4-current.tar.gz debian:/usr/src# rm libpri-1.4-current.tar.gz debian:/usr/src# cd libpri-1.4.9/ debian:/usr/src/libpri-1.4.9# make debian:/usr/src/libpri-1.4.9# make install debian:~# cd /usr/src/ debian:/usr/src# wget http://downloads.digium.com/pub/telephony/dahdi-linux/dahdi-linux-current.tar.gz debian:/usr/src# wget http://downloads.digium.com/pub/telephony/dahdi-tools/dahdi-tools-current.tar.gz debian:/usr/src# tar xvzf dahdi-linux-current.tar.gz debian:/usr/src# tar xvzf dahdi-tools-current.tar.gz debian:/usr/src# rm dahdi-linux-current.tar.gz debian:/usr/src# rm dahdi-tools-current.tar.gz debian:/usr/src# aptitude -y install libusb-dev libnewt-dev debian:/usr/src# cd dahdi-linux-2.2.0.2/ debian:/usr/src/dahdi-linux-2.2.0.2# make Dann die Ausgabe This program built for i486-pc-linux-gnu Fehlermeldungen (auf Englisch) an bug-make@gnu.org senden. debian:/usr/src/dahdi-linux-2.2.0.2# make make -C drivers/dahdi/firmware firmware-loaders make[1]: Entering directory `/usr/src/dahdi-linux-2.2.0.2/drivers/dahdi/firmware' make[1]: Leaving directory `/usr/src/dahdi-linux-2.2.0.2/drivers/dahdi/firmware' You do not appear to have the sources for the 2.6.26-2-686 kernel installed. make: *** [modules] Fehler 1 debian:/usr/src/dahdi-linux-2.2.0.2# kann mir da bitte jemand weiter helfen Mit freundlichen Grüßen Alex Franzke E-Mail: a.fran...@tsp-telecom.de ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Splitting lines problem in make-3.80 versus 3.81
All you have to do is use recursive assignment (=) and NOT simple assignment (:=). The attachment did use =, making the coworker's assertion odder. The lack of need for target-specific variables can be illustrated with a simple example: mart...@whitewater:~/playpen/make-splitting$ cat Makefile PERL_CODE = '\ print STDOUT `cat $(word 2,$^)`; \ ' badger: a b perl -e $(PERL_CODE) a b: echo this file is $@ $@ mart...@whitewater:~/playpen/make-splitting$ rm -f a b mart...@whitewater:~/playpen/make-splitting$ make echo this file is a a echo this file is b b perl -e ' print STDOUT `cat b`; ' this file is b mart...@whitewater:~/playpen/make-splitting$ That was make-3.81. I don't have 3.80 lying around. -Original Message- From: bug-make-bounces+mdorey=bluearc@gnu.org [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Paul Smith Sent: Tuesday, September 08, 2009 13:30 To: warren.l.do...@tektronix.com Cc: bug-make@gnu.org Subject: Re: Splitting lines problem in make-3.80 versus 3.81 On Tue, 2009-09-08 at 13:02 -0700, Warren Dodge wrote: I tried it on my specific problem and indeed it solved the issue. A co-worker was working on another Makefile an having a similar issue. We tried the solution above and ran into a number if strange issues. I haven't looked at this yet but I will. In 3.81 we had to go to greater lengths to get the operation of the Makefile to work. Hee is what the co-worker said about the problem. The variable method can get tricky too, if the perl code you are running makes reference to automatic variables, as they are not defined except in the target. The perl code in question in this example uses the $(word 2,$^) to get name of the second file in the dependency list, so the variable has to be defined as a Target-Specific or Pattern-Specific variable, but making these in a way that is compatible to both 3.80 and 3.81 is not easy. This is definitely not true. All you have to do is use recursive assignment (=) and NOT simple assignment (:=). There is absolutely no difference, other than the line ending concatenation we are trying to take advantage of, between this: foo: echo bar and this: COMMAND = echo bar foo: $(COMMAND) _regardless_ of how complex and what content, variable references, etc. you use to replace echo bar. If you use COMMAND := then definitely you are in for a world of hurt. Assuming there is a bug we hope it can be addressed. If it is just not understanding what is going on maybe the ifo page on this subject can be enhanced to help others address this. I believe that the info is correct and factual. If you try the examples there and follow the instructions you should be successful. I'll take a look at the examples you provided to see if there are holes that need to be clarified, or if you have specific suggestions about things that are hard to understand they're very welcome. As you might guess, when you already know exactly how it all works it can be difficult to write documentation that answers all newcomers' questions in an understandable way. Cheers! ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: executing perl problem with make 3.81 versus 3.80
From make's NEWS file for the 3.81 release:
* WARNING: Backward-incompatibility!
In order to comply with POSIX, the way in which GNU make processes
backslash-newline sequences in recipes has changed. If your makefiles
use backslash-newline sequences inside of single-quoted strings in
recipes you will be impacted by this change. See the GNU make manual
subsection Splitting Recipe Lines (node Splitting Lines), in
section Recipe Syntax, chapter Writing Recipe in Rules, for
details.
-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Warren
Dodge
Sent: Thursday, September 03, 2009 17:15
To: bug-make@gnu.org
Cc: warr...@tektronix.com
Subject: executing perl problem with make 3.81 versus 3.80
I have this Makefile.bug and an empty file yyy which makes no
logical sense as I stripped my
original problem down to this.
-
touch yyy
-
Makefile.bug
-
.PHONY: ggg
ggg:
perl -ne '$$top = x.p.x1.x1; if( $$verilog =~ /^$$/ ) { $$x=1}'
yyy
.PHONY: xxx
xxx:
perl -ne '$$top = x.p.x1.x1; \
if( $$verilog =~ /^$$/ ) { $$x=1}' \
yyy
-
If I use make 3.80 I can make both targets
/tools/gmake3.80/bin/make -f Makefile.bug ggg xxx
perl -ne '$top = x.p.x1.x1; if( $verilog =~ /^$/ ) { $x=1}' yyy
perl -ne '$top = x.p.x1.x1; \
if( $verilog =~ /^$/ ) { $x=1}' \
yyy
If I use make 3.81 I get an error from perl on the xxx target
/tools/wdtgnu/make-3.81/bin/make -f Makefile.bug ggg xxx
perl -ne '$top = x.p.x1.x1; if( $verilog =~ /^$/ ) { $x=1}' yyy
perl -ne '$top = x.p.x1.x1; \
if( $verilog =~ /^$/ ) { $x=1}' \
yyy
syntax error at -e line 2, near if
syntax error at -e line 2, near ;}
Execution of -e aborted due to compilation errors.
make: *** [xxx] Error 255
It appears that something is going wrong on the interfacing of the perl
command into the bash shell which executes the perl.
Here is some information about the 3.81 make.
/tools/wdtgnu/make-3.81/bin/make --debug=j -f Makefile.bug ggg xxx
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i686-pc-linux-gnu
perl -ne '$top = x.p.x1.x1; if( $verilog =~ /^$/ ) { $x=1}' yyy
Putting child 0x099e70a0 (ggg) PID 1624 on the chain.
Live child 0x099e70a0 (ggg) PID 1624
Reaping winning child 0x099e70a0 PID 1624
Removing child 0x099e70a0 PID 1624 from chain.
perl -ne '$top = x.p.x1.x1; \
if( $verilog =~ /^$/ ) { $x=1}' \
yyy
Putting child 0x099e73d0 (xxx) PID 1625 on the chain.
Live child 0x099e73d0 (xxx) PID 1625
syntax error at -e line 2, near if
syntax error at -e line 2, near ;}
Execution of -e aborted due to compilation errors.
Reaping losing child 0x099e73d0 PID 1625
make: *** [xxx] Error 255
Removing child 0x099e73d0 PID 1625 from chain.
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
[bug #27374] fatal error reading included makefile silently ignored
Follow-up Comment #1, bug #27374 (project make): I see the error message: mart...@whitewater:~/playpen/make-27374$ make -f make.bug /dev/null echo success make.bug:1: make.bug: Too many open files success mart...@whitewater:~/playpen/make-27374$ The failure happens (for me) here in the strace: read(1023, include make.bugnnecho ::n...@echo..., 4096) = 41 open(make.bug, O_RDONLY) = -1 EMFILE (Too many open files) open(/usr/include/make.bug, O_RDONLY) = -1 EMFILE (Too many open files) open(/usr/local/include/make.bug, O_RDONLY) = -1 EMFILE (Too many open files) open(/usr/include/make.bug, O_RDONLY) = -1 EMFILE (Too many open files) open(/usr/share/locale/locale.alias, O_RDONLY) = -1 EMFILE (Too many open files) open(/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 EMFILE (Too many open files) open(/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 EMFILE (Too many open files) open(/usr/share/locale/en_US/LC_MESSAGES/libc.mo, O_RDONLY) = -1 EMFILE (Too many open files) open(/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 EMFILE (Too many open files) open(/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 EMFILE (Too many open files) open(/usr/share/locale/en/LC_MESSAGES/libc.mo, O_RDONLY) = -1 EMFILE (Too many open files) write(2, make.bug:1: , 12make.bug:1: )= 12 write(2, make.bug: Too many open files, 29make.bug: Too many open files) = 29 write(2, n, 1 ___ Reply to this item at: http://savannah.gnu.org/bugs/?27374 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: conditionals not working for conditional variables in sub-make?
You misunderstand something. it outputs: VAR=foo VAR2=bar VAR3=foo That's only a small fraction of what I see, with make-3.81. This is what I see: mart...@whitewater:~/tmp/bug-make-2009-05-07$ make make var1 make[1]: Entering directory `/home/martind/tmp/bug-make-2009-05-07' VAR=foo VAR2=bar VAR3=foo make[1]: Leaving directory `/home/martind/tmp/bug-make-2009-05-07' make var2 make[1]: Entering directory `/home/martind/tmp/bug-make-2009-05-07' VAR=bar VAR2=bar VAR3=bar make[1]: Leaving directory `/home/martind/tmp/bug-make-2009-05-07' mart...@whitewater:~/tmp/bug-make-2009-05-07$ Perhaps you want the all rule to say: all: var1 var2 Then I see the desired output: mart...@whitewater:~/tmp/bug-make-2009-05-07$ make VAR=foo VAR2=bar VAR3=foo mart...@whitewater:~/tmp/bug-make-2009-05-07$ -Original Message- From: bug-make-bounces+mdorey=bluearc@gnu.org [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Szekeres István Sent: Thursday, May 07, 2009 02:57 To: bug-make@gnu.org Subject: conditionals not working for conditional variables in sub-make? Please see the makefile attached. by running it it outputs: VAR=foo VAR2=bar VAR3=foo but I think VAR2 should be foo. Bug or do I misunderstand something? thanks, Istvan ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: conditionals not working for conditional variables in sub-make?
But here VAR2 should be foo! No, it shouldn't, for exactly the same reason that VAR2 isn't foo here: mart...@whitewater:~/tmp/bug-make-2009-05-07$ make var1 VAR=foo VAR2=bar VAR3=foo mart...@whitewater:~/tmp/bug-make-2009-05-07$ Despite the number of exclamation marks, it's not clear why you think VAR2 should be foo. Do you think VAR was foo when make was started? Or do you think that make reevaluates all the code at global scope in the context of every target? -Original Message- From: Szekeres István [mailto:szeke...@iii.hu] Sent: Thursday, May 07, 2009 12:58 To: Martin Dorey Cc: bug-make@gnu.org Subject: Re: conditionals not working for conditional variables in sub-make? Hi, 2009/5/7 Martin Dorey mdo...@bluearc.com: That's only a small fraction of what I see, with make-3.81. This is what I see: [...] VAR=foo VAR2=bar VAR3=foo But here VAR2 should be foo As VAR=foo, the ifeq then-branch should set it to foo, but it goes into the else branch - which I think it shouldn't do. Perhaps you want the all rule to say: all: var1 var2 No, it is different. I definitely want the sub-make because I want too runs with VAR substituted to foo in the first run and to bar in the second. As you can see the VAR variable picks up the right value (do-echo outputs foo and then bar) but the ifeq does not pick up the value, basically the ifeq(foo,foo) goes into the else branch. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: conditionals not working for conditional variables in sub-make?
VAR become foo when the var1 rule was executed. it reevaluates because of the explicit make commands in the all rule. Think about the order in which those two things happen. The second one happens before the first and hence doesn't see the first's effect. A thought experiment might help you to see the light. Imagine in the all rule, that instead of running make var1, you ran a-script-which-happens-to-invoke-make-var1. -Original Message- From: Szekeres István [mailto:szeke...@iii.hu] Sent: Thursday, May 07, 2009 14:40 To: Martin Dorey Cc: bug-make@gnu.org Subject: Re: conditionals not working for conditional variables in sub-make? 2009/5/7 Martin Dorey mdo...@bluearc.com: But here VAR2 should be foo! No, it shouldn't, for exactly the same reason that VAR2 isn't foo here: mart...@whitewater:~/tmp/bug-make-2009-05-07$ make var1 VAR=foo VAR2=bar VAR3=foo mart...@whitewater:~/tmp/bug-make-2009-05-07$ Despite the number of exclamation marks, it's not clear why you think VAR2 should be foo. See Target specific variables in the make info. In my example the var1 rule sets VAR to foo (correctly), the var2 rule sets it to bar (correctly). Do you think VAR was foo when make was started? No. VAR become foo when the var1 rule was executed. Or do you think that make reevaluates all the code at global scope in the context of every target? No, it reevaluates because of the explicit make commands in the all rule. The var1 rule sets VAR to foo, and VAR3 is set to $(VAR) globally, and this works correctly, you can see this even in your own output: mart...@whitewater:~/tmp/bug-make-2009-05-07$ make make var1 make[1]: Entering directory `/home/martind/tmp/bug-make-2009-05-07' VAR=foo VAR2=bar VAR3=foo VAR is foo and VAR3 is also foo, correct. make[1]: Leaving directory `/home/martind/tmp/bug-make-2009-05-07' make var2 make[1]: Entering directory `/home/martind/tmp/bug-make-2009-05-07' VAR=bar VAR2=bar VAR3=bar VAR is bar and VAR3 is also bar, correct. The problem is the value of VAR2: in the first case it should be foo, because the if statement ifeq ($(VAR),foo) VAR2=foo else VAR2=bar endif should compare $(VAR) (which is foo in the first case) to foo - they are the same so the then-branch should be executed, setting VAR2 to foo. But in the output you can see that VAR2 is not set to foo, and this is what I reported in my very first mail. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: conditionals not working for conditional variables in sub-make?
(Re-adding list.) First run Second run Make is run three times, once by the human, twice by the makefile. I'm not sure what you mean with this numbering. I think you mean the first and second runs of the echo command in the do-echo rule but please correct me if I'm wrong. These can clearly be seen in your output. I'll reproduce the two lines of echo output here for clarity: VAR=foo VAR2=bar VAR3=foo VAR=bar VAR2=bar VAR3=bar if in the first run VAR3 can pick up the value foo, indicating that VAR is also foo In the first line that I quote above, which is produced by a child of the second make invocation - the one tasked with building var1 - VAR3 is evaluated during the invocation of the do-echo rule as a prerequisite of the var1 rule. Per: There is one more special feature of target-specific variables: when you define a target-specific variable that variable value is also in effect for all prerequisites of this target This means that var1's target-specific assignment of foo to VAR is in effect. VAR3 is defined using deferred evaluation - = rather than := - so the right-hand side of the assignment is deferred to evaluation-time. At evaluation time, as we've seen, the right-hand side - $(VAR) - is foo. why does the statement ifeq($(VAR),foo) fail? That statement is evaluated during an earlier phase of make's execution. It's not reevaluated for every target. At the time, and in the scope, when it was evaluated, $(VAR) was unset, hence empty. -Original Message- From: Szekeres István [mailto:szeke...@iii.hu] Sent: Thursday, May 07, 2009 14:50 To: Martin Dorey Subject: Re: conditionals not working for conditional variables in sub-make? 2009/5/7 Martin Dorey mdo...@bluearc.com: VAR become foo when the var1 rule was executed. it reevaluates because of the explicit make commands in the all rule. Think about the order in which those two things happen. The second one happens before the first and hence doesn't see the first's effect. A thought experiment might help you to see the light. Imagine in the all rule, that instead of running make var1, you ran a-script-which-happens-to-invoke-make-var1. Sorry I am still not convinced. First run: VAR=foo, VAR3 picks up the value of VAR, becoming also foo, correct. Second run: VAR=bar, VAR3 picks up the value of VAR, becoming also bar, correct. Can we agree that these two statements are OK? These can clearly be seen in your output. BUT: if in the first run VAR3 can pick up the value foo, indicating that VAR is also foo, then why does the statement ifeq($(VAR),foo) fail??? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Error 127
This is not a bug in make. It may be a problem with the makefile in question.
Google has a number of matches for 'mpfr no such file or directory' although
none of them grabbed my attention as relevant. I see there's an MPFR mailing
list. That would be the best place to ask, if you've followed their
installation instructions.
From: bug-make-bounces+mdorey=bluearc@gnu.org
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Julio Cesar
Perroni
Sent: Wednesday, May 06, 2009 10:32
To: bug-make@gnu.org
Subject: Error 127
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-2.4.1/tests'
make[2]: Entrando no diretório `/home/jc/Área de Trabalho/mpfr-2.4.1/tests'
make[2]: Nada a ser feito para `install-exec-am'.
make[2]: Nada a ser feito para `install-data-am'.
make[2]: Saindo do diretório `/home/jc/Área de Trabalho/mpfr-2.4.1/tests'
make[1]: Saindo do diretório `/home/jc/Área de Trabalho/mpfr-2.4.1/tests'
make[1]: Entrando no diretório `/home/jc/Área de Trabalho/mpfr-2.4.1'
make[2]: Entrando no diretório `/home/jc/Área de Trabalho/mpfr-2.4.1'
test -z /usr/local/lib || /bin/mkdir -p /usr/local/lib
/bin/sh ./libtool --mode=install /usr/bin/install -c 'libmpfr.la'
'/usr/local/lib/libmpfr.la'
libtool: install: /usr/bin/install -c .libs/libmpfr.so.1.2.0
/usr/local/lib/libmpfr.so.1.2.0
libtool: install: (cd /usr/local/lib { ln -s -f libmpfr.so.1.2.0
libmpfr.so.1 || { rm -f libmpfr.so.1 ln -s libmpfr.so.1.2.0 libmpfr.so.1; };
})
libtool: install: (cd /usr/local/lib { ln -s -f libmpfr.so.1.2.0 libmpfr.so
|| { rm -f libmpfr.so ln -s libmpfr.so.1.2.0 libmpfr.so; }; })
libtool: install: /usr/bin/install -c .libs/libmpfr.lai
/usr/local/lib/libmpfr.la
libtool: install: /usr/bin/install -c .libs/libmpfr.a /usr/local/lib/libmpfr.a
libtool: install: chmod 644 /usr/local/lib/libmpfr.a
libtool: install: ranlib /usr/local/lib/libmpfr.a
/bin/sh: /home/jc/Área: No such file or directory
make[2]: ** [install-libLTLIBRARIES] Erro 127
make[2]: Saindo do diretório `/home/jc/Área de Trabalho/mpfr-2.4.1'
make[1]: ** [install-am] Erro 2
make[1]: Saindo do diretório `/home/jc/Área de Trabalho/mpfr-2.4.1'
make: ** [install-recursive] Erro 1
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
[bug #25697] Segmentation fault setting .DEFAULT_GOAL
Follow-up Comment #1, bug #25697 (project make):
Can reproduce with latest make from CVS. ns is null at the penultimate
line:
2175/* In case user set .DEFAULT_GOAL to a non-existent
target
2176 name let's just enter this name into the table and
let
2177 the standard logic sort it out. */
2178if (default_goal_file == 0)
2179 {
2180struct nameseq *ns;
2181char *p = *default_goal_name;
2182
2183ns = multi_glob (
2184 parse_file_seq (p, '
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
RE: Minor documentation bug
The link to the Errors in Commands section, http://www.gnu.org/software/make/manual/make.html#Errors, explains what the - is for. From: bug-make-bounces+mdorey=bluearc@gnu.org [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Yakup Akbay Sent: Friday, January 30, 2009 05:05 To: bug-make@gnu.org Subject: Minor documentation bug Hi, in chapter '2.7 Rules for Cleaning the Directory' in 'GNU make' document. This is the link to the chapter: http://www.gnu.org/software/make/manual/make.html#Cleanup .PHONY : clean clean : -rm edit $(objects) The minus sign before 'rm' seems to be a clerical error. Regards, Yakup ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: make --guaranteed-real-dry-run
So was this ever resolved? I was happy with the suggestions on the thread, whatever they were, and no-one objected. Did anything get into the documentation? No. If someone were motivated enough to raise a bug, then I expect I could find the time to dig out the old mails, apply them to the current source and generate a patch to attach to the bug. Someone might then commit the changes. -Original Message- From: jida...@jidanni.org [mailto:jida...@jidanni.org] Sent: Friday, January 23, 2009 12:16 To: Martin Dorey Cc: m...@packages.debian.org; bug-make@gnu.org Subject: Re: make --guaranteed-real-dry-run So was this ever resolved? Did anything get into the documentation? Thanks. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Bug in make-3.81: variable_buffer moves out from under buffer
it looks like this bug is still there
And it looks like there are several other instances of it too.
What I am looking for is some help writing a makefile that
is simple enough to post in a bug report.
I had a few goes but it looks like the variable_buffer is always already
big enough by the time it gets here. Can you tell us what rule it falls
over on for you or what trickery might be associated with that rule? Is
there, for example, re-reading of makefiles going on, or $(eval) magic?
-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org
[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 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 find
a bug to report it via Savannah: https://savannah.gnu.org/projects/make/
The code you refer to has been changed in CVS but it looks like this bug
is still there. I also have some changes locally to gain memory
efficiency which might or might not impact it.
Thanks for the report!
-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of David
Wuertele
Sent: Tuesday, January 20, 2009 10:53
To: bug-make@gnu.org
Subject: Bug in make-3.81: variable_buffer moves out from under buffer
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 the savannah buglist and did not find
anything
that resembles it. What I am looking for is some help writing a
makefile that
is simple enough to post in a bug report.
The problem is in expand_deps() in file.c, line 545:
char *o = patsubst_expand (buffer, d-stem, pattern,
dp-name, pattern+1,
percent+1);
if (o == buffer)
dp-name[0] = '\0';
else
{
free (dp-name);
dp-name = savestring (buffer, o - buffer);
}
In the above, the patsubst_expand function calls
variable_buffer_output() with
buffer as the head of the string to write to. But if
variable_buffer_length is
not long enough to hold what patsubst_expand wants to write,
variable_buffer_output() will xrealloc() buffer to a different size,
which could
result in the original contents of buffer getting moved to a different
address.
In this rare case (that I am unable to trigger except in my unpostably
convoluted makefile), the expand_deps() code I quoted above calls
savestring()
on the original value of buffer, which is an address that got freed when
xrealloc moved its original contents. Thus, garbage gets saved in
dp-name.
I have fixed this bug with the following patch. Comments?
Dave
--- make-3.81/file.c~ 2006-03-17 06:24:20.0 -0800
+++ make-3.81/file.c2009-01-16 13:40:30.0 -0800
@@ -545,6 +545,9 @@
char *o = patsubst_expand (buffer, d-stem,
pattern,
dp-name, pattern+1,
percent+1);
+
+ buffer = variable_buffer;
+
if (o == buffer)
dp-name[0] = '\0';
else
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
RE: Bug in make-3.81: variable_buffer moves out from under buffer
In the original makefile, does the long rule really not contain any variables or involve any $(eval) trickery? -Original Message- From: bug-make-bounces+mdorey=bluearc@gnu.org [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of David Wuertele Sent: Tuesday, January 20, 2009 13:44 To: bug-make@gnu.org Subject: Re: Bug in make-3.81: variable_buffer moves out from under buffer Martin Dorey mdorey at 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 I might have missed some --- xrealloc is used really heavily. What I am looking for is some help writing a makefile that is simple enough to post in a bug report. I had a few goes but it looks like the variable_buffer is always already big enough by the time it gets here. Can you tell us what rule it falls over on for you or what trickery might be associated with that rule? Is there, for example, re-reading of makefiles going on, or $(eval) magic? It is a static pattern rule, during the following function: main() - snap_deps() - expand_deps() This function calls patsubst_expand() on the rule target, and when patsubst_expand returns, the original buffer contents have moved. I tried reducing my makefile to just the two rules that trigger the bug (one that sets variable_buffer to the default size of 200, and one that busts beyond it), but somehow I can't get the variable_buffer to stay at 200 before it gets to the static pattern rule. Here's what I expected the reduced makefile to look like: a1: a%: b%; @echo trash a222 2\ 22: a2%: c%; @echo trash But somehow the variable_buffer is already big enough when it gets to the long rule. Dave ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Bug in make-3.81: variable_buffer moves out from under buffer
Thanks. I was hoping it'd be something like that. Even with that clue, though, I'm not having any luck making the buffer need reallocating at the appropriate point. How frustrating. -Original Message- From: bug-make-bounces+mdorey=bluearc@gnu.org [mailto:bug-make-bounces+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 mdorey at 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,many,different,arguments,many,many,many)) somemacro calls other macros: define somemacro $(foreach thing,$(filter-out unwanted-stuff,$(wildcard $1/*)),$(call othermacro,$1,$(thing),$2,$3,and,more,stuff)) endef othermacro calls yet more functions: define othermacro $(patsubst $1/%.x,$3/.y-%,$2): $3/.y-%: $1/%.x; echo blah blah blah endef When I unwind these calls and write the expansion out manually, I invariably change the order that stuff gets evaluated, which results in variable_buffer being large enough to avoid triggering the bug. Dave ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: make --guaranteed-real-dry-run
It's not clear whether you're complaining about rules whose commands are
run even with -n or -t, or whether you're complaining about commands run
by eg $(shell).
Assuming the former, the documentation already explains:
The `-n', `-t', and `-q' options do not affect command lines that begin
with `+' characters or contain the strings `$(MAKE)' or `${MAKE}'. Note
that only the line containing the `+' character or the strings `$(MAKE)'
or `${MAKE}' is run regardless of these options. Other lines in the same
rule are not run unless they too begin with `+' or contain `$(MAKE)' or
`${MAKE}'
That's just below the main description of what -n does, but it looks
like you're reading the summary of the command line switches. There's a
link to the main description right after the sentence you quoted. That
sentence has been further improved in the CVS version to read:
Print the recipe that would be executed, but do not execute it.
@xref{Instead of Execution, ,Instead of Executing the Recipes}.
One reason why I find that to be an improvement is because it's now
clearer that it only refers to commands in recipes, not commands in
variable assignments, conditionals or elsewhere.
Also please document how one can achieve a --guaranteed-real-dry-run.
That would be ignoring the wish of the makefile author that those
commands be run even with -n. More constructively, make --debug might
help you. A program called remake received rave reviews in
http://savannah.gnu.org/bugs/?18617. And, in the last resort, strace
remains excellent.
-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of
jida...@jidanni.org
Sent: Thursday, January 01, 2009 09:12
To: bug-make@gnu.org
Subject: make --guaranteed-real-dry-run
In the documentation everywhere you mention
-n, --just-print, --dry-run, --recon
Print the commands that would be executed, but do not
execute
them.
You should also say:
Well, that is not exactly the truth, in some cases
a even non-malicious programmer can construct a makefile
that will still execute commands. In fact it is quite
common and intentional... The same goes for -t... See
(info (make)MAKE Variable) (info
(make)Options/Recursion).
At least add one word that one still can get wet.
Also please document how one can achieve a --guaranteed-real-dry-run.
Furthermore, one notes in the make --dry-run output that there is no
way to distinguish the lines that were really run from those that
weren't. Only when one sees e.g., /bin/sh: curl-config: command not
found does one notice something sneaky is happening.
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
RE: make --guaranteed-real-dry-run
make --help in CVS has been updated with the recipe clarification but still says: -n, --just-print, --dry-run, --recon\n\ Don't actually run any recipe; just print them.\n I agree that make --help is on particularly dubious ground when saying any recipe. Saying something woolly and referring to the documentation is one thing, but saying something definitive yet, strictly speaking, incorrect, with no caveat or reference, is something else. We need to be concise, so people can find what they're looking for, yet we still need to convey the sense of what the switch does. How about: Don't actually run normal recipes; just print them. -Original Message- From: bug-make-bounces+mdorey=bluearc@gnu.org [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of jida...@jidanni.org Sent: Thursday, January 01, 2009 12:54 To: guent...@gmail.com Cc: bug-make@gnu.org Subject: Re: make --guaranteed-real-dry-run PG The GNU make manpage starts with this: PG WARNING OK, but not make --help. Anyway please change things like -n, --just-print, --dry-run, --recon Don't actually run any commands; just print them. To Don't actually run any commands usually; just print them. The exact wording I leave up to you. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: make switch options
To install this software correctly make must run as follows That sounds like a bug in the documentation you're reading rather than a bug in make. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Siraj Rathore Sent: Friday, November 21, 2008 11:13 To: bug-make@gnu.org Subject: make switch options i am installing a software on debian. To install this software correctly make must run as follows make --with-126 But problem is make is not supporting the switch --with-126. Then i installed gnu make 3.81 but problem is still there. Can you help Regards Siraj ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: possible bug in documentation for make
last updated 04 April 2000, of `The GNU Make Manual', for `make', Version 3.79. I use: GNU Make version 3.79.1 (Wow, that's pretty old skool.) It seems as if it is not possible to change the value of a variable inside an ?ifeq? conditional that test against that very variable That would be a strange and distressing bug, but I would guess you'll find the documentation for the actual cause of the problem if you search for override. The prerequisites are processed from left to right (as one would expect) If your makefile doesn't specify an order (by making one prerequisite depend on another), then the order is deliberately undefined. This gives make the freedom to, for example, build the prerequisites in parallel. A -j switch to invoke that can often be beneficial on modern hardware. Hope that helps, albeit indirectly. - Original Message - From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: bug-make@gnu.org bug-make@gnu.org Sent: Sat Oct 25 13:42:55 2008 Subject: possible bug in documentation for make bug-make@gnu.org. Hello, I found two problems which I think are bugs in the documentation for ?make?: 1) Limitations of redefining a variable inside a conditional are not clear. 2) The order, in which prerequisites are processed, is not clear. I refer to: Edition 0.55, last updated 04 April 2000, of `The GNU Make Manual', for `make', Version 3.79. I use: GNU Make version 3.79.1, Built for i386-pc-msdosdjgpp (not the newest version, I presume, but maybe no one mentioned the problem yet?) 1st problem: In an attempt to reduce tedious typing when defining a variable from the command line, I tried: ifeq (max,$(O)) O = -O3 -fomit-frame-pointer -fno-unroll-loops endif ifeq (,$(O)) O = -O endif CXXFLAGS = -W -Wall $(O) but this didn?t work. After typing ?make O=max? the value ?max? was passed straight to the compiler instead of being changed to ?-O3 -fomit-frame-pointer -fno-unroll-loops?. I had to use the more complex sequence ifeq (max,$(O)) OPTIM = -O3 -fomit-frame-pointer -fno-unroll-loops endif ifeq (,$(O)) OPTIM = -O endif ifndef OPTIM OPTIM = $(O) endif CXXFLAGS = -W -Wall $(OPTIM) It seems as if it is not possible to change the value of a variable inside an ?ifeq? conditional that test against that very variable, but I wasn?t told in the documentation. 2nd problem: In most cases, of course, the order of processing the prerequisites doesn?t matter, but I have to struggle with the limitations of the DOS shell ?command.com?. (Therefore several quirky ways to split long command lines in target ?sicher? of the appended makefile.) I use djgpp?s ?redir? program to create a logfile (?sml.log?), to which the various compiler, assembler and linker messages are appended successively (redir?s option -ea). So, an existing logfile, containing junk from earlier compilations, has to be removed _before_ any other action takes place. I achive this by putting the phony target ?klar? first in the prerequisite list of target ?all?. Phony target ?tst?, showing the final results of compilation, is put last, behind the real target. So far, everything works fine. The prerequisites are processed from left to right (as one would expect). However, when updating the makefile itself (target ?makefile?), the order seems to be the reverse. Command echoing (given in the appended file ?makelog.log?) shows re-generation of ?vid.d? first, followed by ?schirm.d? etc., the first prerequisite??sim.d?, coming last. Prerequisites are processed from right to left! Although this causes no problem, it?s a bit puzzling, and I can?t find anything about it in the documentation. I?d like to suggest that one or two sentences about this be added to the (otherwise very good, not to say exhaustive!) documentation. (Or maybe ?make? itself can be changed to a more consistent behaviour?) Greetings Bernhard Strowitzki Pt! Schon vom neuen WEB.DE MultiMessenger gehört? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #24509] doc for wildcard expansion in commands could be clearer
URL: http://savannah.gnu.org/bugs/?24509 Summary: doc for wildcard expansion in commands could be clearer Project: make Submitted by: mdorey Submitted on: Thu 09 Oct 2008 06:20:47 PM GMT Severity: 3 - Normal Item Group: Documentation Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: CVS Operating System: None Fixed Release: None ___ Details: Harald Bergmann notes that in one place we say the shell is responsible for wildcard expansion where later we say [if you use *.o in a] command, wildcard expansion *will* take place at that time (my emphasis on *will*). Well, perhaps it *will*, perhaps it will not - that depends on the shell, as noted earlier. Further, any expansion doesn't take place at the time make sees the command, which the above wording could reasonably be interpreted to suggest, but only when make runs the shell and the shell runs the command. On the mailing list, I suggested [ I'm not sure I've understood. Perhaps rewording the second stanza like this would address your concern? However, if you use the value $(objects) in a target or prerequisite, wildcard expansion will take place there. If you use the value $(objects) in a command, the shell may perform wildcard expansion when the command runs. ] and the OP replied (privately) [ Hi Martin, I am sure you did! Your proposal is OK! Best regards, Harald ]. That proposal is not quite the same as the patch, from CVS, that I'm attaching here, because the wording has seemingly moved on (using the word recipe instead of command) and because there's quoting in the original that didn't survive the email, leading me to suggest my own $() quoting, above, which I abandon here in favor of the existing style. I reproduce it as evidence that my first paragraph here is an accurate summary of the OP's gripe. ___ File Attachments: --- Date: Thu 09 Oct 2008 06:20:48 PM GMT Name: make.texi.patch Size: 855B By: mdorey http://savannah.gnu.org/bugs/download.php?file_id=16640 ___ Reply to this item at: http://savannah.gnu.org/bugs/?24509 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #24251] Random error including rebuilt makefiles
Follow-up Comment #3, bug #24251 (project make):
I reproduced the behavior you saw without svn by replacing the end of the
makefile with:
$(ECOS_MAKE) : $(ECOS_DIR)
$(ECOS_DIR) :
mkdir -p $(ECOS_DIR)/include/pkgconf/
{
echo 'ECOS_GLOBAL_CFLAGS = -mcpu=arm7tdmi -Wall -Wpointer-arith
-Wstrict-prototypes -Winline -Wundef -Woverloaded-virtual -g -O2
-ffunction-sections -fdata-sections -fno-rtti -fno-exceptions
-finit-priority';
echo 'ECOS_GLOBAL_LDFLAGS = -mcpu=arm7tdmi -Wl,--gc-sections
-Wl,-static -g
-nostdlib';
echo 'ECOS_COMMAND_PREFIX = arm-elf-';
} $(ECOS_MAKE)
Looking at the manual, After all makefiles have been checked, if any have
actually been changed, `make' starts with a clean slate and reads all the
makefiles over again. That suggests that it should re-evaluate all these
variables. But using make --debug=all suggests that make isn't restarting.
Looking at the source code, it seems to be checking whether the modification
time on the makefile has changed:
if (file-updated g-changed
mtime != file-mtime_before_update)
{
/* Updating was done. If this is a makefile and
just_print_flag or question_flag is set
(meaning
-n or -q was given and this file was specified
as a command-line target), don't change STATUS.
If STATUS is changed, we will get re-exec'd,
and
enter an infinite loop. */
But makefile doesn't give a rule for updating $(ECOS_MAKE). It just says
that it depends on $(ECOS_DIR). Telling make that it needn't do anything to
update $(ECOS_MAKE) once it's updated $(ECOS_DIR), by changing:
$(ECOS_MAKE) : $(ECOS_DIR)
To:
$(ECOS_MAKE) : $(ECOS_DIR);
Fixes the problem.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?24251
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
[bug #24251] Random error including rebuilt makefiles
Follow-up Comment #1, bug #24251 (project make): Looks like https://savannah.gnu.org/bugs/?102 to me. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24251 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: dry-run (-n) has no effect with include file generation
It's not dry when the command in question is a recursive call to make either. That's because, in both cases, it's more useful to more people to behave this way by default. If you want a different behavior, you can have your including makefile decide not to include if the included file doesn't exist and MAKECMDFLAGS contains n. I agree that that is sometimes useful. - Original Message - From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: bug-make@gnu.org bug-make@gnu.org Sent: Mon Sep 01 05:34:47 2008 Subject: dry-run (-n) has no effect with include file generation Hi, I noticed that 'make -n' (dry run) is not always like dry, like mentioned in the help: -n, --just-print, --dry-run, --recon Don't actually run any commands; just print them. In my case I have an include statement, which include files which aren't available at make-start-time, but make knows how to generate them. Thus the bug is: If I run 'make -n' then the commands to generate the included files are actually run. I am using make 3.81. Best regards Georg Sauthoff -- Fortune : 'Real programmers don't comment their code. It was hard to write, it should be hard to understand.' ;) ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Order of consideration of missing include files is not documented
The order of generation of any targets that don't have dependencies is not documented. This is deliberate because there is no defined ordering. The targets may even be generated in parallel. - Original Message - From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: bug-make@gnu.org bug-make@gnu.org Sent: Mon Sep 01 05:45:33 2008 Subject: Order of consideration of missing include files is not documented Hi, I noticed that if you include some files in a makefile like include a.d b.d c.d and make knows how to make them, then it firsts generates c.d, then b.d and so on. To me, at least, this reverse order of the include-file-list to generate these files feels counter intuitive. At least it is not documented - if didn't overlook it of course. Best regards Georg Sauthoff -- Fortune : 'Real programmers don't comment their code. It was hard to write, it should be hard to understand.' ;) ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #23928] Add MAKEFILE variable
A B C when parsing C and
A B D when parsing D
That would break the use of $(MAKEFILE_LIST) in dependencies to cause
recompilation when any of the makefiles change. I use that extensively
so, if this were to be implemented, I'd rather it used an additional
variable, perhaps called MAKEFILE_STACK.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, July 28, 2008 03:01
To: bug-make@gnu.org
Cc: [EMAIL PROTECTED]; Martin Dorey; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: RE: [bug #23928] Add MAKEFILE variable
Philip Guenther wrote:
BTW, $(lastword ${MAKEFILE_LIST}) is _not_ always the makefile
being parsed
at that moment, particularly when there's an 'include'
directive earlier in
the makefile. There's in fact no 100% general and reliable
way to get the
name of the file that's being parsed.
Hmm...
Wouldn't MAKEFILE_LIST be more useful if it always contained the list of
makefiles that lead from the top makefile to the current one?
E.g. given makefiles A, B, C and D. If A includes B and B includes D and
then C. Then MAKEFILE_LIST would contain:
A when parsing A,
A B when parsing B,
A B C when parsing C and
A B D when parsing D
Wouldn't that make more sense?
/Lasse
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of ext anonymous
Sent: Saturday, July 26, 2008 08:44
To: Icarus Sparry; Martin Dorey; [EMAIL PROTECTED];
[EMAIL PROTECTED]; bug-make@gnu.org
Subject: [bug #23928] Add MAKEFILE variable
Follow-up Comment #3, bug #23928 (project make):
Icarus Sparry wrote:
You probably want lastword, rather than firstword.
Nope. To quote the original request:
It is often useful to recursively call the current makefile
as part of a rule. Sometimes rules are included from a
different file. The included file may not know the name of
the make file used to start the make process.
The request was for the name of the make file used to start the make
process, which would be $(firstword ${MAKEFILE_LIST}).
(The use of the phrase current makefile is slightly
ambiguous, but I think
the last sentence makes it clear that it is meant to refer to
the makefile
that started the whole deal.)
___
Reply to this item at:
http://savannah.gnu.org/bugs/?23928
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
RE: Help : how to use $(or condition ) $(and condition ) inmakefile
Try make -f and.mk A=22 B=44. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Murphy Sent: Tuesday, June 17, 2008 09:31 To: bug-make@gnu.org Subject: Re: Help : how to use $(or condition ) $(and condition ) inmakefile Hi, I have amended an example of how to use $(and) that I posted earlier for Rakesh. I have tested this on Linux with make 3.81. It shows a crude way and a slightly more sophisticated way to use $(and) in an if statement to determine if two variables have equal values: A=2 B=4 # do equal by seeing if a subst returns the empty string: A_is_2:=$(if $(subst 2,,$(A)),,T) B_is_4:=$(if $(subst 4,,$(B)),,T) AandB:=$(and $(A_is_2),$(B_is_4)) # then you could do something based on this: $(info Crude AND Demo: ) ifneq ($(AandB),) $(info TRUE: A is 2, B is 4) else $(info FALSE: A is $(A), B is $(B)) endif # One could make it look nicer by making an equals macro: define eq $(if $(1:$(2)=),,$(if $(2:$(1)=),,T)) endef # which you could use as follows: $(info Macro-based AND Demo: ) ifneq ($(and $(call eq,$(A),2),$(call eq,$(B),4)),) $(info TRUE: A is 2, B is 4) # do what you want to do when A=2 and B=4 else $(info FALSE: A is $(A), B is $(B)) endif The output looks like this: [EMAIL PROTECTED] base]make -f and.mk A=1 B=5 Crude AND Demo: FALSE: A is 1, B is 5 Macro-based AND Demo: FALSE: A is 1, B is 5 make: *** No targets. Stop. [EMAIL PROTECTED] base]make -f and.mk A=2 B=4 Crude AND Demo: TRUE: A is 2, B is 4 Macro-based AND Demo: TRUE: A is 2, B is 4 make: *** No targets. Stop. [EMAIL PROTECTED] base]make -f and.mk A=2 B=3 Crude AND Demo: FALSE: A is 2, B is 3 Macro-based AND Demo: FALSE: A is 2, B is 3 make: *** No targets. Stop. 2008/6/6 Paul Smith [EMAIL PROTECTED]: On Fri, 2008-06-06 at 05:05 -0700, rakesh aggarwal wrote: But still there is some problem. I haven't looked at your example. But, the very first thing to check is the version of GNU make you're using (make --version). If it's not 3.81, then the manual you're reading is not the right one for the version of GNU make you're using. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: File timing bug
This example is certainly simple, thanks. The Makefile isn't telling make that the rule for making c from d will also update b. Make caches modification times and doesn't know to invalidate its cache of b's time. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Herbert Euler Sent: Monday, June 09, 2008 02:36 To: bug-make@gnu.org Subject: RE: File timing bug Hi, Perhaps due to my long and annoying description, one has difficulty in understanding what the problem I encountered was. Here I would provide a much shorter description. GNU Automake generates dependency tree like this in Makefile.in: [EMAIL PROTECTED]:~/tmp/k$ cat Makefile a: b cat ba b: c c: d dateb cp b c [EMAIL PROTECTED]:~/tmp/k$ Its intention is to regenerate `a' when `d' is updated. But this does not work, since it requires `make' to be executed twice: [EMAIL PROTECTED]:~/tmp/k$ make dateb cp b c [EMAIL PROTECTED]:~/tmp/k$ make cat ba [EMAIL PROTECTED]:~/tmp/k$ However, I noticed that if the Makefile looks like this: [EMAIL PROTECTED]:~/tmp/k$ cat Makefile a: b cat ba b: c cp c b c: d datec [EMAIL PROTECTED]:~/tmp/k$ Everything works as expected: [EMAIL PROTECTED]:~/tmp/k$ touch d [EMAIL PROTECTED]:~/tmp/k$ make datec cp c b cat ba [EMAIL PROTECTED]:~/tmp/k$ Is this a bug in GNU make, or a bug in GNU Automake? Regards, Guanpeng Xu _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: make 3.81 crash: make: double free or corruption (!prev)
Didn't happen for me with the same makefile and similar make, kernel and architecture. In any case it sounds more like bad ram. Suggest burning a CD of http://www.memtest.org/ and leaving it running overnight. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J Jay Sent: Monday, January 28, 2008 08:45 To: bug-make@gnu.org Subject: make 3.81 crash: make: double free or corruption (!prev) $ uname -a Linux localhost.localdomain 2.6.23.14-107.fc8 #1 SMP Mon Jan 14 21:37:30 EST 2008 i686 i686 i386 GNU/Linux $ make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-redhat-linux-gnu $ ls -la total 12 drwxrwxr-x 2 myname myname 4096 2008-01-28 00:11 . drwxrwxr-x 5 myname myname 4096 2008-01-28 17:17 .. -rw-rw-r-- 1 myname myname 87 2008-01-28 00:21 Makefile $ make *** glibc detected *** make: double free or corruption (!prev): 0x095e55a0 *** === Backtrace: = /lib/libc.so.6[0xc53ac1] /lib/libc.so.6(cfree+0x90)[0xc570f0] make[0x80594af] make[0x8059529] make[0x805956c] make[0x804e8b4] make[0x804eb37] make[0x8058408] /lib/libc.so.6(__libc_start_main+0xe0)[0xc00390] make[0x8049951] === Memory map: 0011-00111000 r-xp 0011 00:00 0 [vdso] 00bcb000-00be6000 r-xp fd:00 3440780/lib/ld-2.7.so 00be6000-00be7000 r-xp 0001a000 fd:00 3440780/lib/ld-2.7.so 00be7000-00be8000 rwxp 0001b000 fd:00 3440780/lib/ld-2.7.so 00bea000-00d3d000 r-xp fd:00 3442476/lib/libc-2.7.so 00d3d000-00d3f000 r-xp 00153000 fd:00 3442476/lib/libc-2.7.so 00d3f000-00d4 rwxp 00155000 fd:00 3442476/lib/libc-2.7.so 00d4-00d43000 rwxp 00d4 00:00 0 03ccf000-03cda000 r-xp fd:00 3442485 /lib/libgcc_s-4.1.2-20070925.so.1 03cda000-03cdb000 rwxp a000 fd:00 3442485 /lib/libgcc_s-4.1.2-20070925.so.1 08048000-0806e000 r-xp fd:00 946405 /usr/bin/make 0806e000-0807 rw-p 00025000 fd:00 946405 /usr/bin/make 095da000-095fb000 rw-p 095da000 00:00 0 b7c0-b7c21000 rw-p b7c0 00:00 0 b7c21000-b7d0 ---p b7c21000 00:00 0 b7d54000-b7f54000 r--p fd:00 920101 /usr/lib/locale/locale-archive b7f54000-b7f56000 rw-p b7f54000 00:00 0 bff05000-bff1a000 rw-p bffea000 00:00 0 [stack] Aborted $ cat Makefile all: t.o t.o t.o: t.h \ tt $ Note the backslash. Also, that was the minimum number of t's I could use to crash it, and I had to use a minimum of 3 t.o files. None of the files need to exist. Sometimes (with a slightly changed Makefile) you just get a segmentation fault without any output. I've only tested this on one machine (Fedora 8 latest updates). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: THIS PROGRAM BUILT FOR i686-pc-cygwin
When a make command MAKE Any bug report should contain: What exactly did you type? What did the computer say? Paste all of the output into the bug report. Why do think that is a bug? That last point is the most interesting. You don't say what you expect make to do. You don't say which program you're trying to build. You don't say which instructions you're trying to follow. THIS PROGRAM BUILT FOR i686-pc-cygwin Make produces that message when it's asked for version information or when it can't make sense of your arguments. It's not telling you anything useful here. help-make would be a more appropriate list to send your mail to. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jan89 Sent: Tuesday, January 15, 2008 12:20 To: bug-make@gnu.org Subject: THIS PROGRAM BUILT FOR i686-pc-cygwin Hellow plizz HELP my When a make command MAKE cygwin tell my thet THIS PROGRAM BUILT FOR i686-pc-cygwin Whot a must do? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: make command
I need the latest and greatest for Red Hat 9 Try http://rpmfind.net/linux/rpm2html/search.php?query=make. Please though, if you need more help, bear in mind that this mailing list is for bugs with make itself. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelsey Jason-JBPN64 Sent: Monday, January 14, 2008 14:54 To: bug-make@gnu.org Subject: make command I am trying to configure expect on my system. I need the correct make file my system, i copied over in attempt to trouble shoot errors without making a backup of the old. I need the latest and greatest for Red Hat 9. I believe it was GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i386-redhat-linux-gnu I copied over it with GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Jason Kelsey Technical Support Engineer Embedded Computing Emerson Network Power T +1 972.277.4688 [EMAIL PROTECTED] Motorola's Embedded Communications Computing group is now a business of Emerson Network Power. www.emersonnetworkpower.com/embeddedcomputing http://www.emersonnetworkpower.com/embeddedcomputing __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: install problem
You haven't installed docbook2man but libieee1284-0.1.6 seems to require it. Google's first match for your error message looks to have some advice for exactly this error: http://canon-fb330p.sourceforge.net/howto-fb630p-english This mailing list is for bugs with make. That isn't a make bug. Good luck. I fear you may need it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles H.D.W Sent: Thursday, December 13, 2007 07:38 To: bug-make@gnu.org Subject: install problem I want to instal libieee1284-0.1.6 but when i gift make command, it always diplay: docbook2man -o doc doc/interface.sgml make: docbook2man: Command not found make: *** [doc/ieee1284_claim.3] Error 127 please gift me a solution... ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: canonicalization/stripping of leading ./
http://www.gnu.org/software/make/manual/make.html#Makefile-Basics suggests you follow your final suggestion, as you (seem to) have a $(srcdir) variable. It suggests ./ otherwise, although I've tripped over doing that and generally use $(CURDIR)/ myself. It's helpful elsewhere that ./file and file are considered to be the same file. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 12:53 To: bug-make@gnu.org Subject: canonicalization/stripping of leading ./ Here's an example makefile: cat _EOF Makefile test.out: ./script.sh $ $@ _EOF Now when I run make, it executes `script.sh test.out` instead of `./script.sh test.out` This is all fine when 'PATH=.:stuff', and sometimes acceptable when 'PATH=stuff:.'; but in the general case, its very bad. I'm working around this by changing my makefiles to cat _EOF Makefile test.out: ./script.sh ./$ $@ _EOF but that doesn't seem too good either; maybe it should always be cat _EOF Makefile test.out: $(srcdir)/script.sh $(srcdir)/$ $@ _EOF ?? Bug reports #15338 and #17230 cover this same issue, but I haven't seen any followup, neither on Savannah nor on these lists. The closest discussion I could find was #10708, mentioned in http://lists.gnu.org/archive/html/help-make/2006-03/msg00231.html What's the official scoop? Are there plans to fix/change this behavior? In the meantime, how should I code the above Makefile (where an output file should be rebuilt whenever its script changes)? Thanks, Daniel ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #21198] Wrong order of prerequisites with 3.81/CVS
Follow-up Comment #1, bug #21198 (project make): In which order do you think the prerequisites should be built? And why? If C should be built before D, for example, then we have to tell make that D depends on C. Mentioning D after C in a list of prerequisites is not sufficient. Mentioning D on a later line than C is not sufficient. We have to say that D : C, or that D : X where X : C, or D : X where X : Y and Y : C, or similar. The ordering is otherwise up to make and may (and, as you've seen, does) vary from release to release and even from invocation to invocation. With -j, C and D can even be built in parallel. ___ Reply to this item at: http://savannah.gnu.org/bugs/?21198 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #21198] Wrong order of prerequisites with 3.81/CVS
Follow-up Comment #2, bug #21198 (project make): Robin Williams points out there is a different issue here which can be seen by adding $ to the echo command, so the test reads: all : A B C all : ; @echo $@ -- $^, $ all : D E F A B C D E F : ; @echo $@ With that change, make-3.80 says: A B C D E F all -- A B C D E F, A But 3.81 says: A B C D E F all -- A B C D E F, D The manual says: $ The name of the first prerequisite. Here the first prerequisite of all would appear to be A. Interestingly, if the example is reordered such that the prerequisites are all given before the command for building all: all : A B C all : D E F all : ; @echo $@ -- $^, $ A B C D E F : ; @echo $@ Then 3.81 also says $ is A. ___ Reply to this item at: http://savannah.gnu.org/bugs/?21198 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Single-suffix rules broken?
.SUFFIXES = .in Your makefile works for me (with make foo, given a foo.in) if I change that line to read: .SUFFIXES: .in -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ludovic Courtès Sent: Sunday, August 12, 2007 00:30 To: bug-make@gnu.org Subject: Single-suffix rules broken? Hi, I'm trying to use the following single-suffix rule: .SUFFIXES = .in .in: echo dot-in My understanding is that the rule should be triggered whenever there exists a file whose name is equal to the target name plus the `.in' suffix. For instance, make foo should trigger the rule when `foo.in' exists. However, that does not happen. Am I missing something or are single-suffix rules somehow broken? Thanks, Ludovic. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Problem with make...
That sounds unlikely to be a bug with make, so the help-make list would be more appropriate. The make maintainer has a paper on dependencies which you can find here: http://web.archive.org/web/20061205233409/http://make.paulandlesley.org/ autodep.html That focuses on automatic generation of the dependencies but you can probably work out where you're going wrong from it... and you probably also want to generate the dependencies automatically. If that doesn't help, you'll need to post a copy of your makefile or, preferably, an minimal part of it that demonstrates your problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sreerajgel Sent: Sunday, August 05, 2007 23:55 To: Bug-make@gnu.org Subject: Problem with make... hai all, am really lost with this...plz help...i have a C, HDR and DEP folder under the root folder...as names suggest C folder contains all the source files HDR contains all the headers and I created the dependencies and put them in to the DEP folder. I have included the path of .d files in DEP in my makefile. My problem is, when I modify any header and then try to recompile its not taking the dependencies. ie the source files in which this particular headers are included are not getting recompiled...but if I modify any source file and then recompiles its compiling that file...Simply, the changes I make in HDR are not getting affected in the Build...i hope u understand and plz tell me where i should have gone wrong Thanks for the support -- ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #20033] parallel (-j2) make with $(eval) construct segfaults
Follow-up Comment #2, bug #20033 (project make): (I can reproduce a crash with that example.) ___ Reply to this item at: http://savannah.gnu.org/bugs/?20033 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #19900] Target-specific variables not honored for rules generated by $(eval)
Follow-up Comment #1, bug #19900 (project make): See the note about double expansion here: http://www.gnu.org/software/make/manual/make.html#Eval-Function You want the rule to read: echo $$(var) That then works for me. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19900 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #19035] Make recompiles source files eventhough the files are not modified
Follow-up Comment #2, bug #19035 (project make): Also, if your source was last written on machine A and you're now trying to compile those files on machine B and machine B's clock is so far behind machine A's that the source files' timestamps still appear to be the future, then you'd see this behavior. You would probably also see warnings about clock skew - so when you post your small example of a makefile, please post the output you see too, so we can eliminate that. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19035 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: BUG while running the make file
Yes, that is a bug *while running* make. Perhaps we should rename the mailing list to [EMAIL PROTECTED] or otherwise try to indicate in the error message that this isn't likely to be a bug in make. Perhaps we're doomed though. For one thing, this bug looks unlikely to be a bug in lprng, which is where we'd have tried to send the user if we'd have tried to automatically suggest where the bug is. I'd have to suspect a gcc misconfiguration, which might be diagnosed with the help of the suggestion here: http://sources.redhat.com/ml/crossgcc/2006-01/msg00221.html Or an assembler bug which might have been already reported here: http://sourceware.org/bugzilla/show_bug.cgi?id=3830 My five minutes of googling didn't turn up a more certain or complete answer, I'm afraid. All I can tell you for sure is that it isn't a bug in make. I downloaded the Debian source for lprng and I couldn't see any obvious assembler, specifically not in linksupport.c, so I don't think you've got an lprng-specific problem, unless lprng is somehow using the wrong gcc or assembler. I didn't find anything in google suggesting that anyone's seen this before with lprng, which suggests it's more likely something peculiar to your system or a bug in a different package (like gcc or gas). Sorry, but I don't think we can help you any further on this list. Good luck. - Martin's Outlook, BlueArc Engineering From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raheja, Himanshu Sent: Wednesday, February 07, 2007 8:52 To: bug-make@gnu.org Subject: BUG while running the make file Hi, I am trying to Install LPRng on my Red Hat Linux Box (x86_64). After executing ./configure I am typing make and getting following errors : /bin/sh ../libtool --mode=compile 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/linksupport.c 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/linksupport.c -o linksupport.o /tmp/ccsjrIuh.s: Assembler messages: /tmp/ccsjrIuh.s:1368: Error: Incorrect register `%rax' used with `l' suffix /tmp/ccsjrIuh.s:1617: Error: Incorrect register `%rax' used with `l' suffix make[1]: *** [linksupport.lo] Error 1 make[1]: Leaving directory `/home/gams/lprng/LPRng-3.8.28/src' make: *** [src] Error 2 Kindly look into this matter and let me know what needs to be done. I will be really grateful. Thanks and Regards Himanshu ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: BUG while running the make file
2007-02-07-15:28:15.682 sbkdgdbdev1 Init_tempfile: bad tempdir '/var/spool/lpd/%P' ... *** glibc detected *** double free or corruption (fasttop): 0x080a0bc8 *** Now those are definite lprng issues. Suggest googling or taking that to an lprng list. This list is only for bugs in make. We try to be helpful but you're talking to the wrong guys. - Martin's Outlook, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raheja, Himanshu Sent: Wednesday, February 07, 2007 13:02 To: Dave Korn; Eli Zaretskii Cc: bug-make@gnu.org Subject: RE: BUG while running the make file One more help needed from you guys. I have two LPRng versions installed on my Linux box. I have binaries for LPRng 3.6.9 under /usr/local/bin. I have installed the latest LPRng 3.8.28 and I was successfully able to compile in 32 bit mode. Binaries for this are kept in /usr/local/sbin. While I am running LPRng 3.8.28 (/usr/local/sbin.) I get following errors: 2007-02-07-15:28:15.682 sbkdgdbdev1 Init_tempfile: bad tempdir '/var/spool/lpd/%P' 2007-02-07-15:28:15.683 sbkdgdbdev1 Init_tempfile: bad tempdir '/var/spool/lpd/%P' 2007-02-07-15:28:15.684 sbkdgdbdev1 Init_tempfile: bad tempdir /var/spool/lpd/%P' If I am running LPRng 3.6.9 I get following errors: *** glibc detected *** double free or corruption (fasttop): 0x080a0bc8 *** *** glibc detected *** double free or corruption (fasttop): 0x080a0bc8 *** Kindly help and suggest what could be done. Thanks and Regards Himanshu. -Original Message- From: Dave Korn [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 1:48 PM To: Raheja, Himanshu; 'Eli Zaretskii' Cc: bug-make@gnu.org Subject: RE: BUG while running the make file On 07 February 2007 18:44, Raheja, Himanshu wrote: Hi Folks, I was able to resolve that issue by googling: When I ran ./configure CFLAGS=-m32 LDFLAGS=-m32 And after that make install was working fine. But I am not sure why this was happening. Probably because your compiler is a recent one, and defaults to compiling 64-bit code, but your binutils are slightly out of date and have bugs trying to assemble the 64-bit code. The -m32 flag that you have found out to use makes sure the compiler still generates 32-bit code, which the binutils do not have any problem with. So you end up with a 32-bit executable. (It might be possible to upgrade your binutils and get the build to work for 64 bits, and the resulting executable might run faster, but it's not something to try unless you were confident with upgrading packages and knew how to revert to the old one if something went wrong.) cheers, DaveK -- Can't think of a witty .sigline today ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Need Help
help-make might be an appropriate mailing list to send this request to. Googling for a make tutorial might turn up something useful. There's always the make manual, which contains a fairly simple example: http://www.gnu.org/software/make/manual/make.html#Simple-Makefile You might, however, be after a higher-level tool that just Does The Right Thing. automake's the most well-known higher level tool for posix systems. There's an example on using that at http://www.amath.washington.edu/~lf/tutorials/autoconf/toolsmanual.html#SEC33. It's not as simple as you might hope and, it's a shame, but I don't know of a simple, ubiquitous alternative. Sorry and good luck! - Martin's Outlook, BlueArc Engineering From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of souvik sadhu Sent: Sunday, February 04, 2007 23:12 To: bug-make@gnu.org Subject: Need Help Hi.. Give me the steps for execution of make. Suppose i have 3 .c and 1 .h file. what should i do to make a make file. I m using gcc compiler. Just write the code with any rule and dependenvy.(as u want) and after this what i have to do to produce a make file. tell me the command by which i have to compile and execuite this make file. waiting for your reply regards Souvik No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18963] -include suppressing errors for too long?
Follow-up Comment #1, bug #18963 (project make): -include never issues warnings or errors. I'd previously suggested a change to that section of the manual in http://lists.gnu.org/archive/html/bug-make/2007-01/msg2.html. Perhaps you'd like to suggest a further or alternative change to make this clearer? http://make.paulandlesley.org/autodep.html shows how the make maintainer recommends that you do automatic dependency generation and inclusion, if that's what you're trying to achieve here. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18963 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: RE: [bug #18641] GNUmake 3.81, $(error ) sometimes unable to stop make process
I feel that the description for -include is still quite vague I'm sure it won't address all of your concern about the documentation in this area but, as a small step in the right direction, I'd suggest changing the section here: If you want make to simply ignore a makefile which does not exist and cannot be remade, with no error message, use the -include directive instead of include, like this: -include filenames... This acts like include in every way except that there is no error (not even a warning) if any of the filenames do not exist. For compatibility with some other make implementations, sinclude is another name for -include. To read: If you want make to simply ignore a makefile which does not exist and cannot be remade, with no error message (not even a warning), use the -include directive instead of include, like this: -include filenames... For compatibility with some other make implementations, sinclude is another name for -include. The lack of and cannot be remade in the sentence I've removed seems likely to cause confusion, as here, and that sentence wasn't adding anything except (not even a warning) which could be moved to the first sentence, as in my suggestion. I can not accomplish this using GNUmake 3.81 . Have you tried using $(wildcard) on the name you pass to the include directive (rather than -include)? Perhaps you could contrive something devious to achieve your goal along those lines. That might remove the need for difficult discussions about whether it's necessary to preserve the (arguably broken) previous behavior of -include. - Martin's Outlook, BlueArc Engineering -Original Message- From: Chen Jun (陈军) [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 03, 2007 19:57 To: Martin Dorey; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; bug-make@gnu.org Subject: Re: RE: [bug #18641] GNUmake 3.81,$(error ) sometimes unable to stop make process Hello, Martin Dorey, Thank you very much for your investigation, now I've realized that the source of my problem on GNUmake 3.81 is the leading dash before include directive. It's a pity that this behavior change is not expressed in the NEWS file in GNUmake 3.81 source package. However, on revisiting the GNUmake manual(manual of v3.81), I feel that the description for -include is still quite vague. The manual says in chapter 3.3 Including Other Makefiles: -include filenames… This acts like include in every way except that there is no error (not even a warning) if any of the filenames do not exist. For compatibility with some other make implementations, sinclude is another name for -include. What does no error (not even a warning) if any of the filenames do not exist mean? There are two time points that make will check the existence of the to-be-included files, one is the first start of a makefile, another is the second start(restart) after all included targets are remade. For a user using GNUmake 3.80, he can only observe the behavior difference(as for whether add the dash) at the first time point that I mentioned(the difference is whether a warning is printed) ; no make hehavior difference can be observered at the second time point(make process stops on failing to make an included target). Now, GNUmake 3.81 really changed(or fix) the behavior since 3.80. I do not protest this fix -- it's a new feature after all, however, the GNUmake author should not have broken the behavior compatibility after 3.80 had been used widely for three years. If possible in GNUmake 3.82, I'd like to suggest using double dash(i.e. --include some-files) for current 3.81's behavior, while singe dash remains the same behavior as 3.80 . Just forcing the current 3.80 user to remove the dash before include is not good. Take my situation for example, I require the included files to exist when make is restarted(else the make process must halt), but at make's first start, I don't like the end-user to see lots of warnings saying No such file or directory for my designated included files. You see, I can not accomplish this using GNUmake 3.81 . By the way, my problems mentioned above arose when I was trying my GNUmake-based auto-building system (called GnumakeUniproc) on GNUmake 3.81. The GnumakeUniproc project has just been approved by sourceforge.net today(unix name = gnumakeuniproc), and hopefully you can see its first beta release in a month or two. === You wrote: == Suggest rewriting the last two lines as: Sorry for that unnecessary nonsense. I'm not sure why I invented that superstition. Now I'm at a proper computer (and can read the documentation and try things out), I can reproduce the behavior observed by the OP. A potentially relevant difference in behavior between 3.80 and 3.81 can be observed with a simpler makefile: -include Makefile1 Makefile1: false -include Makefile2 Makefile2: false
Re: [bug #18641] GNUmake 3.81, $(error ) sometimes unable to stop make process
To get the behavior you want, you need the rule for $(_p_SubprjsMade) to fail
when its invocation of ${MAKE} -f $(_p_mk_MakeSubPrjs) fails. Suggest
rewriting the last two lines as:
@${MAKE} -f $(_p_mk_MakeSubPrjs) \
touch $@
(echo -n $@ is fine - touch $@ is just more usual and shorter.)
This way, the parent make will stop when the sub-make fails.
As to why make-3.81 behaves differently to make-3.80, that requires a deeper
knowledge of make's internals than I have. All I can say is that I have
noticed make-3.81 seeming to reassess the list of targets which need building
more often than 3.80 but someone else might chime in with a fuller
explanation.
- Original Message -
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
To: Jun Chen [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL
PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED];
bug-make@gnu.org bug-make@gnu.org
Sent: Sat Dec 30 06:03:44 2006
Subject: [bug #18641] GNUmake 3.81, $(error ) sometimes unable to stop make
process
URL:
http://savannah.gnu.org/bugs/?18641
Summary: GNUmake 3.81, $(error ) sometimes unable to stop
make process
Project: make
Submitted by: chjfth
Submitted on: Saturday 12/30/2006 at 22:03
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Component Version: 3.81
Operating System: Any
Fixed Release: None
___
Details:
I think I've found in GNUmake 3.81 a hard-to-realize bug. This bug causes
$(error ) function unable to stop the whole make process. I encountered this
bug recently when I'm developing an auto-building system based on
GNUmake(called GnumakeUniproc), and I have isolate the smallest
makefile(filename: eGmu.makefile, 30 effective lines, see the attached file)
that can reproduce this problem.
Be aware, in order to see this bug, you have to `rm
_MainPrjBuildStart.gmu.ckt' before invoking my makefile, -- honestly, you
just have to do it.
Output from make 3.81:
===
[chj @vchjsuse101 ~/test/clear381]
$ make381 -f eGmu.makefile
make381[1]: Entering directory `/home/chj/test/clear381'
_SubprjsAttr.gmu.mki:1: *** == Hey! you should stop here!
[./_MakeSubPrjs.gmu.mk] ==. Stop.
make381[1]: Leaving directory `/home/chj/test/clear381'
_SubprjsAttr.gmu.mki:1: *** == Hey! you should stop here! [eGmu.makefile]
==. Stop.
===
You can see that `` some-makefile:line-number: *** error message.
Stop.'' appears more than once, which is not the correct behavior.
GNUmake 3.80 does not have this bug however. Output from make 3.80:
===
[chj @vchjsuse101 ~/test/clear381]
$ make380 -f eGmu.makefile
make[1]: Entering directory `/home/chj/test/clear381'
_SubprjsAttr.gmu.mki:1: *** == Hey! you should stop here!
[./_MakeSubPrjs.gmu.mk] ==. Stop.
make[1]: Leaving directory `/home/chj/test/clear381'
make: *** [_SubprjsMade.gmu.ckt] Error 2
===
My testing environment:
* SuSE Linux 10.1 with stock make 3.80.
* And I build make 3.81 from official source on SuSE Linux 10.1 with command
./configure make .
###
Finally, I also post my eGmu.makefile here:
_IsP1OlderThanP2 = $(if $(wildcard $1),$(shell (if [ $1 -ot $2 ];then echo -n
'1';fi)),1)
# If file $1 not exist or older than $2, 1 is returned, else null is
returned.
# If $2 does not exist, result is undetermined.
_IsOlderThanPrjStart = $(call _IsP1OlderThanP2,$1,$(_p_MainPrjStart))
_ClearFile = echo -n $(1)
gmu_Gd_PRJ_GMUTMP = .
_StartupSignatureFile = _MainPrjBuildStart.gmu.ckt
ifeq ($(MAKELEVEL),0)
export _p_MainPrjStart = $(CURDIR)/$(_StartupSignatureFile)
# Important! User should first delete it before invoking the makefile of
the main-project!
#Otherwise, the build can be incomplete.
ifeq (,$(wildcard $(_p_MainPrjStart))) # Do these only if the
main-prj-start signature does not exist.
# The first thing here is to create the main-prj-start signature, so
that
the code
# in this if/endif will only execute once during one whole build
process.
_temp := $(shell if (echo -n $(_p_MainPrjStart)) ; then echo -n '';
\
else echo __GMU_ex_ERROR; fi; )
ifneq (,$(_temp))
$(error !GMU!Error: Cannot create start-up signature
file($(_StartupSignatureFile)) in current dir)
endif
endif # ifeq (,$(wildcard $(_p_MainPrjStart)))
endif # ifeq ($(MAKELEVEL),0)
_p_mki_SubprjAttr = $(gmu_Gd_PRJ_GMUTMP)/_SubprjsAttr.gmu.mki
_p_SubprjsAttrMade = $(gmu_Gd_PRJ_GMUTMP)/_SubprjsAttrMade.gmu.ckt
_p_mk_MakeSubPrjs = $(gmu_Gd_PRJ_GMUTMP)/_MakeSubPrjs.gmu.mk
RE: [bug #18641] GNUmake 3.81, $(error ) sometimes unable to stop make process
Suggest rewriting the last two lines as:
Sorry for that unnecessary nonsense. I'm not sure why I invented that
superstition.
Now I'm at a proper computer (and can read the documentation and try
things out), I can reproduce the behavior observed by the OP. A
potentially relevant difference in behavior between 3.80 and 3.81 can be
observed with a simpler makefile:
-include Makefile1
Makefile1:
false
-include Makefile2
Makefile2:
false
$ make #3.81
false
false
make: *** No rule to make target `Makefile1'. Stop.
$ make-3.80
false
make-3.80: *** [Makefile2] Error 1
$
If I remove the - from -include, then make-3.81 stops after the
first failure to update a makefile. The 3.81 behavior of -include seems
consistent with the documentation - that make shouldn't stop if the
makefile can't be remade. So I think I'd say that the difference in
behavior is due to a bug with 3.80's -include which is fixed in 3.81.
The OP said:
$(error ) function unable to stop the whole make process
But there are two make processes. One was stopped and the other carried
on, as it was (arguably) instructed to do by the - on the -include
directive.
Double apologies if I've got the wrong end of the stick again but I felt
duty bound to correct my earlier mistake... and then duty bound to try
to make some more useful contribution. I have to admit that I haven't
fully understood the attached makefiles. Hopefully --debug=all gave me
enough insight.
-
Martin's Outlook, BlueArc Engineering
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin
Dorey
Sent: Saturday, December 30, 2006 7:05
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
bug-make@gnu.org
Subject: Re: [bug #18641] GNUmake 3.81,$(error ) sometimes unable to
stop make process
To get the behavior you want, you need the rule for $(_p_SubprjsMade) to
fail when its invocation of ${MAKE} -f $(_p_mk_MakeSubPrjs) fails.
Suggest rewriting the last two lines as:
@${MAKE} -f $(_p_mk_MakeSubPrjs) \
touch $@
(echo -n $@ is fine - touch $@ is just more usual and shorter.)
This way, the parent make will stop when the sub-make fails.
As to why make-3.81 behaves differently to make-3.80, that requires a
deeper knowledge of make's internals than I have. All I can say is that
I have noticed make-3.81 seeming to reassess the list of targets which
need building more often than 3.80 but someone else might chime in
with a fuller explanation.
- Original Message -
From: [EMAIL PROTECTED]
[EMAIL PROTECTED]
To: Jun Chen [EMAIL PROTECTED]; [EMAIL PROTECTED]
[EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED];
[EMAIL PROTECTED] [EMAIL PROTECTED]; bug-make@gnu.org
bug-make@gnu.org
Sent: Sat Dec 30 06:03:44 2006
Subject: [bug #18641] GNUmake 3.81, $(error ) sometimes unable to stop
make process
URL:
http://savannah.gnu.org/bugs/?18641
Summary: GNUmake 3.81, $(error ) sometimes unable to
stop
make process
Project: make
Submitted by: chjfth
Submitted on: Saturday 12/30/2006 at 22:03
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Component Version: 3.81
Operating System: Any
Fixed Release: None
___
Details:
I think I've found in GNUmake 3.81 a hard-to-realize bug. This bug
causes
$(error ) function unable to stop the whole make process. I encountered
this
bug recently when I'm developing an auto-building system based on
GNUmake(called GnumakeUniproc), and I have isolate the smallest
makefile(filename: eGmu.makefile, 30 effective lines, see the attached
file)
that can reproduce this problem.
Be aware, in order to see this bug, you have to `rm
_MainPrjBuildStart.gmu.ckt' before invoking my makefile, -- honestly,
you
just have to do it.
Output from make 3.81:
===
[chj @vchjsuse101 ~/test/clear381]
$ make381 -f eGmu.makefile
make381[1]: Entering directory `/home/chj/test/clear381'
_SubprjsAttr.gmu.mki:1: *** == Hey! you should stop here!
[./_MakeSubPrjs.gmu.mk] ==. Stop.
make381[1]: Leaving directory `/home/chj/test/clear381'
_SubprjsAttr.gmu.mki:1: *** == Hey! you should stop here!
[eGmu.makefile]
==. Stop.
===
You can see that `` some-makefile:line-number: *** error message.
Stop.'' appears more than once, which is not the correct behavior.
GNUmake 3.80 does not have this bug however. Output from make 3.80:
===
[chj @vchjsuse101 ~/test/clear381]
$ make380 -f eGmu.makefile
make[1]: Entering directory `/home/chj/test/clear381'
_SubprjsAttr.gmu.mki:1: *** == Hey! you should stop here!
[./_MakeSubPrjs.gmu.mk] ==. Stop.
make[1]: Leaving
Re: getting warmer error messages
it fails with a message saying that target cannot be built. That's close to what it says but the OP's right that, strictly speaking, the message make produces isn't actually true. If it said no rule whose prerequisites can be built to make target then it would be true but verbose. I can see that the intention behind the error message is to be more helpful but some correctness has been lost. Target %s cannot be built sounds like an excellent suggestion to me - it's short and clear and accurate. there are usually many possible pattern rules which it MIGHT match, if it could build the prerequisites An example might help persuade - % is often make-able from %.c - so any list of potentially missing prerequisites would have to include %.c. I'm tempted to suggest that I might sometimes find the list of missing prerequisites useful when debugging but perhaps it would be so explosively large that it wouldn't be useful even as an option. I do OK with make -p anyway. - Original Message - From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: Dan Jacobson [EMAIL PROTECTED] Cc: bug-make@gnu.org bug-make@gnu.org Sent: Thu Dec 28 00:29:51 2006 Subject: Re: getting warmer error messages I can only assume you're trying to prove a point by making this bug report virtually unintelligible, with no concrete suggestions for improvement. Well played. Unfortunately for your point, there's a good reason for make's behavior. Pattern rules only match if make can successfully create all the prerequisites in the rule. If one or more cannot be created, then the pattern rule does not match. If no pattern rule matches for a given target (and no explicit rules exist for it), then make can't figure out how to build that target and so it fails with a message saying that target cannot be built. What else should it do? For any given target there are usually many possible pattern rules which it MIGHT match, if it could build the prerequisites. The default pattern rules, by themselves, provide a number of ways of building any file, and a multitude of ways to build some types of file. I don't believe it would be useful for make to print a list of potential targets that, if they could be built, would allow the target you asked for to be built. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #18517] Compilation error in find_directory() in dir.c on Windows platforms
p[-1] = '\0'; What makes you think this is a compilation error? Do you have a compiler error message for us? I suspect that you're just worried about indexing an array with -1. p isn't an array. It's previously been assigned by: p = name + strlen (name); So -1 is only an invalid index if strlen(name) == 0. I was going to say surely that never happens? but I do see calls, albeit #ifdef AMIGA, which do pass an empty string to find_directory. - Martin's Outlook, BlueArc Engineering ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #18517] Compilation error in find_directory() in dir.c onWindows platforms
Did you miss the fact that p is const? Doh, yes, sorry. - Martin's Outlook, BlueArc Engineering ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: can't get far if file has difficult name
Isn't this more relevant? (Quoting from here on.) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul D. Smith Sent: Saturday, November 25, 2006 14:09 To: Paul D. Smith; [EMAIL PROTECTED]; bug-make@gnu.org Subject: [bug #18369] pattern rules don't work with spaces in filenames Update of bug #18369 (project make): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #1: The short answer is, GNU make doesn't handle filenames with spaces in them. Make is really not a filename manipulator, it's a string parser. And it uses whitespace to delimit strings in all aspects of its implementation and behavior. Anyway, this is a duplicate of bug #712 - Martin's Outlook, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Grant Sent: Thursday, November 30, 2006 13:26 To: Dan Jacobson Cc: bug-make@gnu.org Subject: Re: can't get far if file has difficult name Hi Dan Jacobson elucidated on 30/11/06 17:14: $ cat Makefile .PRECIOUS:.%.time %.t:.%.time; .%.time:% bla bla bla $ ls -1 Makefile 霧峰-桐林(有經朝陽科技大學) - Wufeng-Tonglin (Via Zhaoyang Technical University) Well, no amount of quoting will enable me to $ make '霧峰-桐林(有經朝陽科技大學) - Wufeng-Tonglin (Via Zhaoyang Technical University)'.t make: *** No rule to make target ... If those Asian characters are a filename you need to specify -f filename when you call make if you would like to process that file. Otherwise if you would like to process your Makefile Just call make with no arguments. Cheers Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug
However, your point about programs invoked by make inheriting the
setrlimit() is definitely something that seems problematic. Perhaps
GNU
make could change the stack limit back to what it was after it forks
but
before it execs its child. I wonder what happens if you change a
limit to
something too small for the current processes resources?
It doesn't look specified by
http://www.opengroup.org/onlinepubs/009695399/functions/getrlimit.html.
This test suggests that it works fine on my Linux box. I presume the
limit check is normally done on a faulting access off the end of the
stack, so setrlimit would need some to have some different and special
code to check the current stack usage if it wanted to apply the check
immediately. It seems a bit unlikely that anyone would have gone to
that effort, thus stopping you from doing something useful in this sort
of situation.
#include alloca.h
#include errno.h
#include iostream
#include stddef.h
#include string.h
#include sys/time.h
#include sys/resource.h
void useLotsOfStack(size_t size);
size_t getAndDisplayStackLimit() {
rlimit resourceLimit;
if (getrlimit(RLIMIT_STACK, resourceLimit) 0) {
std::cerr getrlimit failed with errno std::endl;
}
std::cout rlim_cur == resourceLimit.rlim_cur std::endl;
std::cout rlim_max == resourceLimit.rlim_max std::endl;
return resourceLimit.rlim_cur;
}
void setStackLimit(size_t size) {
rlimit resourceLimit;
resourceLimit.rlim_cur = size;
if (setrlimit(RLIMIT_STACK, resourceLimit) 0) {
std::cerr setrlimit failed with errno std::endl;
exit(1);
}
getAndDisplayStackLimit();
}
int main() {
size_t initialLimit = getAndDisplayStackLimit();
//useLotsOfStack(initialLimit * 10);
setStackLimit(initialLimit * 100);
useLotsOfStack(initialLimit * 10);
setStackLimit(initialLimit);
useLotsOfStack(initialLimit * 10);
}
void useLotsOfStack(size_t size) {
memset(alloca(size), 0, size);
}
-
Martin's Outlook, BlueArc Engineering
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
RE: can't get far if file has difficult name
I'd be interested to see the same test with odd characters but not whitespace. Works for me if I remove the two close-parentheses and replace the white space with underscores. Open-parenthesis fine, close-parenthesis bad. Weird. Close-parenthesis is also bad with Debian sarge's make-3.80. The non-ASCII characters seem to work fine. - Martin's Outlook, BlueArc Engineering -Original Message- From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Thursday, November 30, 2006 16:22 To: Jon Grant Cc: Martin Dorey; bug-make@gnu.org; Dan Jacobson Subject: Re: can't get far if file has difficult name On Thu, 2006-11-30 at 22:51 +, Jon Grant wrote: Martin Dorey elucidated on 30/11/06 21:32: Isn't this more relevant? (Quoting from here on.) Yeah, Looking at it again I can see that's likely the problem. I might need to reopen that bug; there definitely was a change in behavior WRT filenames containing spaces between 3.80 and 3.81. I need to look at it to see what's going on. I'd be interested to see the same test with odd characters but not whitespace. As far as I know, GNU make is UTF-8 compatible. But I know very little about it. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: can't get far if file has difficult name
You didn't specify what errors you got when you had the parens in
there
Here you go:
[EMAIL PROTECTED]:~/tmp/make-2006-11-30$ ls -l bracket*
-rw-rw-r-- 1 martind software 0 2006-11-30 16:44 bracket(
-rw-rw-r-- 1 martind software 0 2006-11-30 16:44 bracket()
[EMAIL PROTECTED]:~/tmp/make-2006-11-30$ make 'bracket()'.t
make: *** No rule to make target `bracket().t'. Stop.
[EMAIL PROTECTED]:~/tmp/make-2006-11-30$ make 'bracket('.t
bla bla bla
make: bla: Command not found
make: *** [.bracket(.time] Error 127
[EMAIL PROTECTED]:~/tmp/make-2006-11-30$
Which is to say that I quoted them and got an error from make.
-
Martin's Outlook, BlueArc Engineering
-Original Message-
From: Paul Smith [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 30, 2006 18:27
To: Martin Dorey
Cc: Jon Grant; bug-make@gnu.org; Dan Jacobson
Subject: RE: can't get far if file has difficult name
On Thu, 2006-11-30 at 16:52 -0800, Martin Dorey wrote:
Works for me if I remove the two close-parentheses and replace the
white
space with underscores. Open-parenthesis fine, close-parenthesis bad.
Weird. Close-parenthesis is also bad with Debian sarge's make-3.80.
I suspect that has to do with the shell. Although () are not special to
make, they are special to the shell, and make's builtin rules don't
quote their filename arguments (and neither did Dan's example).
You didn't specify what errors you got when you had the parens in there,
but in my tests if I have them (unquoted) I get an error from the shell,
not from make.
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug
Using heap, which requires a system call to get more memory
(It doesn't affect the main point of Paul's reply but just for academic
interest) no it doesn't:
[EMAIL PROTECTED]:~/playpen$ cat ten-thousand-mallocs.c
#include stdlib.h
int main() {
for (int ii = 0; ii != 10 * 1000; ++ ii) {
free(malloc(1));
}
}
[EMAIL PROTECTED]:~/playpen$ g++ ten-thousand-mallocs.c
[EMAIL PROTECTED]:~/playpen$ strace ./a.out 21 | wc -l
152
[EMAIL PROTECTED]:~/playpen$
Even in less contrived applications, brk isn't called anything like as
often as malloc.
-
Martin's Outlook, BlueArc Engineering
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #17529] Variable set with $(shell date '+%Y%m%d-%H%M%S') changes mid-make
http://www.gnu.org/software/make/manual/html_node/Flavors.html How about expanding: The two flavors are distinguished in how they are defined and in what they do when expanded. To say: The two flavors are distinguished in how they are defined, in what they do when expanded and in which phase of make's operation they are expanded (see the discussion of deferred versus immediate expansion in Reading Makefiles). How about also adding a cross-reference to the Reading Makefiles, Variable Assignment section to say something like: Variables whose expansion is deferred are also referred to as recursively expanded variables. Variables which are immediately expanded are also known as simply expanded variables. See The Two Flavors of Variables. - Martin's Outlook, BlueArc Engineering ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #17529] Variable set with $(shell date '+%Y%m%d-%H%M%S') changes mid-make
base = xxx-$(shell date '+%Y%m%d-%H%M%S') Perhaps you wanted := instead of =. The difference is explained in (for example): http://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html #Reading-Makefiles - Martin's Outlook, BlueArc Engineering ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #17529] Variable set with $(shell date '+%Y%m%d-%H%M%S') changes mid-make
all variables are expanded exactly once - whether they are immediate or deferred No. It might sound like that but that's definitely, definitely, definitely not what happens. Deferred variables are expanded again every time they're used. I thought perhaps I'd quoted the wrong part of the documentation because, reading it again, I think you're right that it isn't clear. Searching for deferred didn't find me any other, clearer part. Perhaps a clarification patch would be in order. Try the := idea. I bet you can't break it. Another idea that might be more convincing: base = $(shell date --iso=ns 12) That sends the output of date(1) to stderr, where you'll see it directly, once for each time it's invoked. - Martin's Outlook, BlueArc Engineering ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: bugs seems on eval function
I don't know why. Sounds like a bug I hit too - https://savannah.gnu.org/bugs/?func=detailitemitem_id=1516 - which is fixed in make-3.81. 2. some compare funcitons like compare of numbers maybe usefull Yeah, using the Peano numbers gets tedious after the initial thrill at using something from your CompSci degree wears off. Might be worth filing an RFE on the Savannah page if there isn't one. - Martin's Outlook, BlueArc Engineering From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ??? Sent: Tuesday, August 22, 2006 8:48 To: bug-make@gnu.org Subject: bugs seems on eval function Dear sir, Thank you very much for your write and provide powerfullmake for people and for me.. I use GNU make 3.80 running on Win32 (form WindRiver Systems Workbench 2.4) and find a strange problem that the make's internal function eval not work properly... function eval not work properly.it can describe as follows.. when use eval to insert some code to the makefile it sometimes generate errors. I have to files named makefile.ok and makefile.bad..and the veiw.ouput.JPG file is the output of the make the makefile.ok can generate and insert the object dependency OK.but the makefile.bad generate errors said endif not found..but when the statement: $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog been removed. the makefile.bad has no errors in it...I don't know why. BTW: 1. I found it will be very usefull to dynamiclly generate and insertdependency rules to the makefile..so if has a function that can directly insert a variables value to makefile will be good.like : MY_STATEMENT = $(foo) : xx.oyy.o $(LD) -o $(foo)-rxx.oyy.o ###MY_STATEMENT can be dynamic generate by exist functions. ###and a function insert can directly insert the statement to the makefile.like $(insert $(MY_STATEMENT)) 2. some compare funcitons like compare of numbers maybe usefull and some loop funcitons like while for may also be usefull. I am a new beginer on using make,so could you please forgive me if i am fool on something. Thank you very much!!! Best Regards, Yao pinggang 22-aug-06 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: possible bug in gnu make regarding dereferenced constructed variable names used in conditionals
Thanks for your polite report. I think you've been bitten by one of make's design quirks, documented by this section in the manual ($ is an automatic variable): Conditional Statements -- All instances of conditional syntax are parsed immediately, in their entirety; this includes the `ifdef', `ifeq', `ifndef', and `ifneq' forms. Of course this means that automatic variables cannot be used in conditional statements, as automatic variables are not set until the command script for that rule is invoked. If you need to use automatic variables in a conditional you _must_ use shell conditional syntax, in your command script proper, for these tests, not `make' conditionals. There are solutions other than using shell conditions. For example, you can have several alternate rule bodies defined in variables and then choose which rule to execute based on the value of an automatic variable. Rules like this aren't uncommon: target: prerequisite $(COMPILE$(suffix $)) $ -o $@ Hope that helps. - Martin's Outlook, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred T. Hamster Sent: Saturday, August 05, 2006 10:57 To: bug-make@gnu.org Subject: possible bug in gnu make regarding dereferenced constructed variable names used in conditionals dear gnu, thanks for developing gnu make. i rely on it daily. i was trying to extend my makefiles recently and found what looks to me like a bug. i'm including an example makefile that's hopefully stripped down enough. what i was expecting is that a variable name could be constructed within a variable expression and then dereferenced. in one case this seems to work great (in an echo statement), but in another case (an ifeq conditional), it seems to be treated incorrectly as null when it should have contents. i have GNU Make 3.80 running on a suse 10.0 linux system (x86). i've also tried it and gotten the same results with version 3.81 on a debian sarge system. here's the makefile output from the sample makefile: --- [EMAIL PROTECTED] $ make cleaning up compilation products. building product.o flags evaluated to nothing! this seems erroneous! the first part, the evaluates to: product.cpp the flags replacement on that turns into: product.cpp_FLAGS the full dereference evaluates to: show_extra_info building product.exe --- the expected print-out was not seen; instead the seems erroneous message above gets shown. this comes from the conditional in the example makefile, where instead i would expect the other message to be shown: --- we had extra flags that we'd have done something with. this seems like the correct behavior. --- the last print out in the make run is the fully evaluated expression and it is not an empty string (it evaluated to show_extra_info), yet the ifeq conditional claims that the expression is equal to null. that seems incorrect. while trying to figure out what was going on, i tried both ifeq and ifneq to compare against a null value. they both consistently seem to return the opposite result from the expected one. first i questioned my sanity and understanding of boolean algebra. then i questioned whether this type of dereferenced variable is intended to be supported or not, but the echo statement later in the makefile shows the expression that i'm expecting from the construct. i'm including the example makefile that uses the dereferenced variable approach plus the basically empty source file used in the makefile. thanks very much if you could look into this. certainly further thanks are due if you could let me know if it's a bug or not. in general, thanks very much for the gnu software. -chris koeritz aka fred t. hamster (internet pseudonym) -- ___ chosen by the Nechung Oracle Program [ http://gruntose.com/ ] ___ ,,ggddYYbbgg,, ,agd888b,_ Y8, ___`Ybga, ,gdPbaa,.8b888g, ,dP ]8P' Y `888Yb, ,dP ,P db, 8PYb, ,8 ,8b, da 8, ,8'd888,88P' a, `8, ,8' 88PP `8, d' I888P `b 8 `888PY8P' 8 8Y 8[ _ 8 8 Y8d8b Y a 8 8 `8d, __ 8 Y,`8bd888b, ,P `8, ,d888baaa ,8' `8,' ,8' `8a 88I a8' `Yba `Y888P'adP' Yba `88P' adY `Yba, dP ,adP' Normand Veilleux `Y8baa, ,d888P,ad8P' from ``YYbaP'' Spaceship Earth _ not
RE: Bug Report (SUN Sparc Kernel-2.4)
A quick google for the error message turned up a fourth line, saying: !!! If you need support, post the topmost build error, NOT this status message. However, this list is for bugs in gnu make and your problem is far more likely to be with something gentoo-specific. We don't know anything about gentoo here. When reporting a make bug, you'd want to supply the necessary part of the makefile, the output from make and an explanation of why you think make is in error. (None of the output you supplied was from make.) - Martin's Outlook, BlueArc Engineering From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence W. Thorne Sent: Sunday, July 09, 2006 16:28 To: bug-make@gnu.org Subject: Bug Report (SUN Sparc Kernel-2.4) Following your directions (Gentoo handbook) Installing Necessary System Tools (Section 9) At 9.a. Device Manager: udev is not available for unmerging and when I attempt to merge devfsd I get the following error/bug !!! ERROR: sys-fs/devfsd-1.3.25-r9 failed. !!! Function src_compile line 566, Exitcode 2 !!! emake failed NOTE: Apparently UDEV is not supported for 2.4 kernel, but 2.4 kernel is default for Sparc 64 bit processor). -lt Lawrence Thorne CEO/President Thorne Digital Media Group, Inc. 1133 Broadway Ste #606 New York, NY 10010 Email: [EMAIL PROTECTED] Office: (212) 206-7804 Fax: (212) 504-3169 Cell: 646-734-8989 24 hour Support: [EMAIL PROTECTED] This email may contain material that is confidential or proprietary to Thorne Digital Media Group, Inc. and is intended solely for use by the intended recipient. Any review, reliance or distribution of such material by others, or forwarding of such material without express permission, is strictly prohibited. If you are not the intended recipient, please notify the sender and destroy all copies. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Clock skew detected warning
Any intelligent operating system will store timestamps in a canonical format that does not jump around wildly when changing timezones or entering/exiting daylight savings. Yes, and Windows does this. I don't use Windows so I don't know how it works: maybe it does the intelligent thing, too, and there's something else wrong here. Yes. One common reason is that a system adminstrator has chosen to override the default clock synchronization mechanism (which, these days, is a passable implementation of ntp) and to synchronize the clock to local time, rather than to the One True UTC by some other method. My first port of call would be to find out the time zone configuration of the machine in question and how its clock is being synchronized. -- Martin's BlackBerry, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: Li, Shiping (Sam) [EMAIL PROTECTED] CC: bug-make@gnu.org bug-make@gnu.org Sent: Sun Apr 02 22:22:06 2006 Subject: Re: Clock skew detected warning %% Li, Shiping \(Sam\) [EMAIL PROTECTED] writes: ls I am using gnumake to build a code and got below errors: ls gnumake[2]: warning: Clock skew detected. Your build may be ls incomplete. ls . ls gnumake.exe[1]: *** Warning: File `../../videoss/mp4/dec/src/mp4d_mb.d' ls has modification time in the ls future (2006-04-02 22:48:35 2006-04-02 21:49:07) ls ls I think normally people met this problem in NFS server because of ls the clock sync problem, but they are talking about 2 seconds at ls most. In my case, it is one hour! ls I think it may caused by summer time, it started today (April 2nd) ls and it is the first day of summer time. I met this problems in ls two PCs. I am using winXP and all the files are stored locally. Well, if this is true then Windows has a stupid implementation of timestamps. Any intelligent operating system will store timestamps in a canonical format that does not jump around wildly when changing timezones or entering/exiting daylight savings. I don't use Windows so I don't know how it works: maybe it does the intelligent thing, too, and there's something else wrong here. You might consider asking on the make-w32@gnu.org mailing list to see if they have any advice there... this is a Windows-specific issue and they know much more about Windows than the folks reading this list. Good luck! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #9062] Need access to pathname of Makefile
Follow-up Comment #7, bug #9062 (project make): From the make ChangeLog: 2002-10-03 Paul D. Smith [EMAIL PROTECTED] Version 3.80 released. 2002-06-06 Paul D. Smith [EMAIL PROTECTED] ... * read.c (read_all_makefiles): Create a new built-in variable, MAKEFILE_LIST. 2000-06-23 Paul D. Smith [EMAIL PROTECTED] * Version 3.79.1 released. And, from ChangeLog.2: 1998-05-20 Paul D. Smith [EMAIL PROTECTED] * Version 3.76.90 released. 1998-04-11 Paul D. Smith [EMAIL PROTECTED] * main.c (main): Set the CURDIR makefile variable. Fri Sep 19 09:20:49 1997 Paul D. Smith [EMAIL PROTECTED] * Version 3.76.1 released. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=9062 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: mixed implicit rules problem
make could not figure out full graph of implicit rules From the info pages: 4.12.2 Static Pattern Rules versus Implicit Rules ... An implicit rule _can_ apply to any target that matches its pattern, but it _does_ apply ... only when the prerequisites can be found. ... By contrast, a static pattern rule applies to the precise list of targets that you specify in the rule. It cannot apply to any other target and it invariably does apply to each of the targets specified. YMMV but I got into the habit of always using static pattern rules some years ago. - Martin's Outlook, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yaroslav Halchenko Sent: Tuesday, March 28, 2006 18:20 To: bug-make@gnu.org Subject: mixed implicit rules problem Dear Makers, I thought that it is a bug in the recent make since I've first encountered this situation while fixing RC bug in Debian distro (make of version 3.80+3.81.rc2-1) but it is also present on slightly older system running 3.80-9. To make it short -- here is an example ( taken from my bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351646 ) cat Makefile SO=1 T=2 VER=$(SO).$(T) lib%.so:lib%.so.$(SO) ln -snf $$(basename $) $@ lib%.so.$(SO):lib%.so.$(VER) ln -snf $$(basename $) $@ a/b/c/lib%.so.1.2: a/b/c/libz%.so cat $ | $@ rm a/b/c/* -f /var/tmp/test# echo 1 a/b/c/libzz.so.1.2 /var/tmp/test# make a/b/c/libz.so make: *** No rule to make target `a/b/c/libz.so'. Stop. /var/tmp/test# make a/b/c/libz.so.1.2 ln -snf $(basename a/b/c/libzz.so.1.2) a/b/c/libzz.so.1 ln -snf $(basename a/b/c/libzz.so.1) a/b/c/libzz.so cat a/b/c/libzz.so | a/b/c/libz.so.1.2 rm a/b/c/libzz.so a/b/c/libzz.so.1 /var/tmp/test# make a/b/c/libz.so ln -snf $(basename a/b/c/libz.so.1.2) a/b/c/libz.so.1 ln -snf $(basename a/b/c/libz.so.1) a/b/c/libz.so rm a/b/c/libz.so.1 As you can see, make could not figure out full graph of implicit rules on how to derive libz.so from libzz.so.1.2. Please advise -- is it me not fully understanding something or there is something to fix? Please CC in replies - I am not on any list -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07105 Student Ph.D. @ CS Dept. NJIT ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16132] Quoting problem in 3.81rc1
Follow-up Comment #15, bug #16132 (project make): I've been using make 3.80 with cygwin sh.exe quite comfortably for the past 2 years. But which make 3.80? The Cygwin one or the Windows native one? They're quite different configurations. If you're trying to replace a Cygwin make with a native one, that would explain the change in behavior. That's what Eli was getting at in comment #13. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16132 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: bug in 3.8.0
I'm between a rock and a hard place. I know - I'm in a similar position. Having code which reliably generates rules (with $eval) is a powerful feature and, once you've tasted it, it's hard to give it up. However, I've been using the 3.81 beta builds very successfully on a number of platforms for many months. Debian's testing distribution has had 3.81 beta builds for a couple of months now. It's good to go, or very nearly so. 3.8.1 isn't released yet. Not for long. Paul's making a serious effort to get 3.81 released - the hope is it will be this very week. make-3.81rc2 is now available from ftp://alpha.gnu.org/gnu/make (in case you're still using a beta build). The previous (3.80) release of make was about three and a half years ago. Hopefully 3.82 won't take as long but, if 3.81rc2 exhibits any problems in your production environment, now would be a really, really good time to report them. - Martin's Outlook, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of PATTON, BILLY (SBCSI) Sent: Friday, March 17, 2006 4:53 To: bug-make@gnu.org Subject: bug in 3.8.0 define build_proj_template $(1): $(foreach bb,$(BB_$(patsubst build+%,%,$(1))),$(addsuffix +$(bb),$(addprefix build+,$(patsubst build+%,%,$(1) @echo build_proj_template $(1) endef $(foreach proj,$(PROJECTS),$(eval $(call build_proj_template,$(addprefix build+,$(proj) If I change the eval to warning 3.79ok 3.79.1 ok 3.8.0 ok 3.8.1 ok change warning back to eval 3.79nothing 3.79.1 nothing 3.8.0 segmentation fault core dump 3.8.1 ok Since 3.8.1 is beta. It cannot put it to a production environment. I'm between a rock and a hard place. 3.79 is installed but doesn't work. The impact is taking a hard look at upgrading some of the servers to 3.8.0. but it failes. 3.8.1 isn't released yet. Segmentation fault (core dumped) (gdb) bt #0 0xc0199cbc in _sigfillset+0x26fc () from /usr/lib/libc.2 #1 0xc0197e18 in _sigfillset+0x858 () from /usr/lib/libc.2 #2 0xc0198cfc in _sigfillset+0x173c () from /usr/lib/libc.2 #3 0xc0195bec in _sscanf+0x8fc () from /usr/lib/libc.2 #4 0xc019b510 in realloc+0x1a0 () from /usr/lib/libc.2 #5 0x1f738 in xrealloc ( ptr=0x40018f78 build+ldb : build+ldb+inftp build+ldb+opi build+ldb+schapi build+ldb+tuxapi build+ldb+ldngn build+ldb+in fgn build+ldb+ldgn build+ldb+ld Address 0x40019000 out of bounds, size=4294965501) at misc.c:384 #6 0xb5ec in variable_buffer_output (ptr=0x40018810 @[EMAIL PROTECTED], string=0x40018498 , length=1) at expand.c:67 #7 0xba08 in variable_expand_string (line=0x40018810 @[EMAIL PROTECTED], string=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj, length=-1) at expand.c:207 #8 0xc0e4 in variable_expand (line=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj) at expand.c:415 #9 0xc224 in variable_expand_for_file ( line=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj, file=0x0) at expand.c:457 #10 0xc510 in allocated_variable_expand_for_file ( line=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj, file=0x0) at expand.c:555 #11 0x11478 in func_foreach (o=0x40017bf8 build_proj_template, argv=0x68ff1870, funcname=0x36a98 foreach) at function.c:874 #12 0x12c80 in expand_builtin_function (o=0x40017bf8 build_proj_template, argc=3, argv=0x68ff1870, entry_p=0x40003604) at function.c:1864 #13 0x12fd8 in handle_function (op=0x68ff17a4, stringp=0x68ff17a8) at function.c:1964 #14 0xbac8 in variable_expand_string (line=0x40017bf8 build_proj_template, string=0x40017390 $(foreach proj,$(PROJECTS),$(eval $(call build_proj_template,$(addprefix build+,$(proj), length= 91) at expand.c:235 #15 0x21c38 in eval (ebuf=0x68ff1574, set_default=1) at read.c:913 #16 0x20828 in eval_makefile (filename=0x40015148 XXX, flags=0) at read.c:379 #17 0x201a8 in read_all_makefiles (makefiles=0x4000fe70) at read.c:205 #18 0x1b390 in main (argc=3, argv=0x68ff0694, envp=0x68ff06a4) at main.c:1444 (gdb) ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: help
Title: help This mailing list is for reporting and discussing bugs in make rather than for help with installation difficulties. You would probably be better off downloading an executable from, perhaps, http://www.mingw.org/download.shtml or using Cygwin's setup tool. You'd be even better off finding someone locally that you can talk to about the best way to achieve what you're trying to do. - Martin's Outlook, BlueArc Engineering From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Tellamalla Sent: Monday, February 20, 2006 9:32 To: bug-make@gnu.org Subject: help Hi, While I am trying to install the Gnu make in to my system it is showing that make is failed and goto dosbuild.bat It is also not showing every thing it is showing like evcery thing is no; So if u know please help me regarding this project currently we are in Globalization project. ThanksRegards Robert T [EMAIL PROTECTED], +91 9986460068 Ph: 080-25522059, ext: 608 www.g-c-i.com ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #15757] circular variable_set_list causes hang on SunOS
Follow-up Comment #10, bug #15757 (project make): It's a long shot and Paul's method looks like a more constructive way of progressing but I just thought I'd mention bug #15534. There, make got confused by an apparent inode number collision, caused by only considering the bottom 32 bits of the 64 bit inode number. Some versions of Solaris might use 64 inode numbers and, the bigger the build, the more likely you are to see a collision. The bug's fixed in CVS, so it'd be a relatively easy one to eliminate. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15757 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Static Rules Unceremoniously Dropped
( As documented in info make, 10.5.1: `%' in a prerequisite of a pattern rule stands for the same stem that was matched by the `%' in the target. In order for the pattern rule to apply, its target pattern must match the file name under consideration, and its prerequisite patterns must name files that exist or can be made. ) - Martin's Outlook, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul D. Smith Sent: Tuesday, January 31, 2006 14:35 To: William Ahern Cc: help-make@gnu.org; Bug-make@gnu.org Subject: Re: Static Rules Unceremoniously Dropped %% William Ahern [EMAIL PROTECTED] writes: wa Using 3.81beta3, it seems that one of our pattern rules wa CFLAGS_$(d) := -DFOO wa $(d)/%.o: $(d)/%.c -lfoo -lbar wa $(CC) $(CFLAGS_$(@D)) ... wa is dropped without notice when -lbar is not found. Note that wa LIBPATTERNS is nullified, and -lfoo and -lbar are explicit wa .INTERMEDIATE targets (or are supposed to be when they're wa present). wa Then, the default %.o: %.c rule matches, but cannot properly wa compile the source because of missing CFLAGS. wa This seems like a bug, because there is absolsutely no notice that wa the rule was dropped or the dependency could not be found. Maybe wa this issue rises from LIBPATTERNS code, and thus slips thru the wa cracks. wa I've moved a HUGE source tree over to a non-recursive make model. wa Fortunately this is the only bug we've hit so far, IIRC. wa I've debugged and debugged. Rest assured that $(d) is defined wa correctly, etc, etc. The only way to trigger it is to remove the wa rule definition for -lbar. I'm not exactly sure what you want make to do here. As far as I can understand from your explanation, the pattern rule wasn't dropped. Rather, a pattern rule matches only if all the prerequisites either exist or can be created. If one or more don't, then the pattern rule doesn't match and make looks for another pattern rule that does work. If one of the prerequisites is an explicit file (not a pattern) then that file still has to either exist or be creatable by make. Make doesn't report every pattern rule that does not match; that would generate a LOT of useless output. If you use -d you should see it try and discard that pattern because -lbar doesn't exist and make doesn't know how to create it. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: make management problems
I didn't succeed to find ( ) the way to make the MAKE to stop after the predefined number of errors has occurred. ( or after the some file has failed to compile ) make does, by default, stop at the first error it encounters. (Perhaps that isn't sufficiently clear in the manual - you could submit a documentation patch.) So this will probably turn out to be a problem with your makefile or (less likely) the way you're invoking make. This mailing list is, however, for reporting and discussing bugs in make itself, rather than in makefiles. - Martin's Outlook, BlueArc Engineering From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrey Scatchakov Sent: Sunday, January 29, 2006 5:41 To: bug-make@gnu.org Subject: make management problems Dear GNU team, I use CodeWrite 6.5 and http://www.gnu.org/software/make/manual/html_mono/make.html#SEC_Top. Unfortunately I didn't succeed to find ( ) the way to make the MAKE to stop after the predefined number of errors has occurred. ( or after the some file has failed to compile ). The MAKE compile all files, with no reaction on an error. Will you be so kind to show me the way to stop compilation process ( rest of files ). Thanks in-advance, regards, Andrey. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: GNU Make 3.80 problem on Solaris 8
NFS filesystems (at least not NFSv2 or NFSv3) don't support sub-second timestamps That's definitely not true. NFSv3 supports nanosecond timestamp resolution. This isn't just a theoretical capability. I'm looking at a file on a Solaris box exported with NFSv3 to a Linux client, showing a microsecond precision timestamp all the way up the stack to the ls -l --full-time output. touch(1) on my Linux NFSv3 client won't send a sub-microsecond precision timestamp over the wire to a server which supports the full nanosecond resolution (a BlueArc Titan). I'm not sure where in the stack the nanoseconds have been rounded off, though utimes(2) would be my guess. The behavior of my Linux boxes over the last few months/year makes me think that this http://www.kerneltraffic.org/kernel-traffic/kt20040605_260.html#6 was eventually resolved by rounding ext3 file times to a precision of one second in cache as well as on disk. A few minutes of googling failed to confirm this, though, and I'm not quite motivated enough to dive into the source. Perhaps that's what Paul was thinking of. - Martin's Outlook, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul D. Smith Sent: Tuesday, December 13, 2005 6:27 To: [EMAIL PROTECTED] Cc: bug-make@gnu.org Subject: Re: GNU Make 3.80 problem on Solaris 8 %% Warren L Dodge [EMAIL PROTECTED] writes: wld I can't believe this is the first time we have noticed this in wld the two years we have been using 3.80. One thing to note is that NFS filesystems (at least not NFSv2 or NFSv3) don't support sub-second timestamps. So, building on an NFS filesystem won't have this issue, only local filesystems. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: GNU Make 3.80 problem on Solaris 8
I thought it wasn't until NFSv4 they were supported but I guess it was NFSv3. NFSv2 supported microsecond resolution (search for useconds in http://www.faqs.org/rfcs/rfc1094.html). I've got a feeling that you're right, though, in as much as it was only implemented to a second resolution in Linux. I may well be wrong - it's been a few years since anyone asked me any questions about NFSv2. - Martin's Outlook, BlueArc Engineering -Original Message- From: Paul Smith [mailto:[EMAIL PROTECTED] On Behalf Of Paul D. Smith Sent: Tuesday, December 13, 2005 11:08 To: Martin Dorey Cc: [EMAIL PROTECTED]; bug-make@gnu.org Subject: RE: GNU Make 3.80 problem on Solaris 8 %% Martin Dorey [EMAIL PROTECTED] writes: NFS filesystems (at least not NFSv2 or NFSv3) don't support sub-second timestamps md That's definitely not true. NFSv3 supports nanosecond timestamp md resolution. This isn't just a theoretical capability. I'm md looking at a file on a Solaris box exported with NFSv3 to a Linux md client, showing a microsecond precision timestamp all the way up md the stack to the ls -l --full-time output. Ah, OK. I got my versions mixed up. I thought it wasn't until NFSv4 they were supported but I guess it was NFSv3. md touch(1) on my Linux NFSv3 client won't send a sub-microsecond md precision timestamp over the wire to a server which supports the md full nanosecond resolution (a BlueArc Titan). I'm not sure where md in the stack the nanoseconds have been rounded off, though md utimes(2) would be my guess. It was strange, but filesystems supported subsecond timestamps well before there was any system interface to set them. That is, you could retrieve them but not set them... so tools like tar, cp -p, etc. couldn't preserve the subsecond part. I think this has been resolved now, maybe in SuS, but I don't remember the details and I'm sure there are many tools out there which still don't support them (tar has a bigger problem in that they'd need to be preserved in the archive format). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Problem with gmake.
Can you explain me why the del command can not be found? del is part of cmd.exe, not a separate program. cmd /c del *.h will work. rm *.h will probably work (if you have enough of cygwin installed to run make, then you probably have rm). I have a problem with gmake. This list is really for problems with make itself, not makefiles. - Martin's Outlook, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sergei Sent: Wednesday, December 07, 2005 22:33 To: bug-make@gnu.org Subject: Problem with gmake. Hello, I have a problem with gmake. My makefile contains the following: -- clean: del *.h -- when i perform the command: make clean i get the error message: make: del: command not found make: *** [clean] Error 127 Can you explain me why the del command can not be found? When I type manually in command console: del *.h It is work ok! Can you also tell me how to fix this proble? My environment: OS: WindowXP gmake version: 3.79.1 Best regards, Sergey. --- http://auto.ngs.ru - в продаже более 1200 авто ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: 'fhandler_base::dup:' - Error
Google suggests that your error message comes from the cygwin dll. I notice that you're using a version of make that's more than 3 years old. Perhaps you might like to see if the problem's reproducible with the latest released version of cygwin and its build of make? All of the google matches I found seemed similarly old - perhaps the problem has been fixed. - Martin's Outlook, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, November 21, 2005 13:18 To: bug-make@gnu.org Subject: 'fhandler_base::dup:' - Error I have been using MSYS-MINGW-GCC to compile and link my C++ code. The problem I am having is following error. Building GCCAltiaGui.exe Executing: C:\Rhapsody6.1\Share\etc\cygwinmake.bat GCCAltiaGui.mak clean Setting environment for Cygwin make.exe 0 [main] make 2772 fhandler_base::dup: dup(some disk file) failed, handle 0, Win32 error 6 Cleanup Clean Done This happens when I try to execute 'make' for the first time. The version of 'make' is 3.79.1. Version of GCC is 3.2.3. The build is on Windows 2000 machine. Could you please point me to some fixes to resolve this error. Regards, Amit Sheth GMNA - Software and Controls [EMAIL PROTECTED] ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: 'fhandler_base::dup:' - Error
Regardless of which gcc you're using, you appear to be using the cygwin version of make - and it's the cygwin dll in that make process that's hit an error. So you need to report a cygwin problem but, I'd suggest (again), first try a newer version of cygwin. - Martin's Outlook, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, November 21, 2005 14:45 To: Paul D. Smith Cc: bug-make@gnu.org Subject: Re: 'fhandler_base::dup:' - Error Let me clarify. Setting environment for Cygwin is just a comment in the batch file that calls 'make'. I am using 'Cygwin' settings, but trying to get MSYS-MINGW-GCC to work instead of CygwinGCC. The batch file is @echo off PATH=C:/MSYS/1.0/bin;%PATH% rem set INCLUDE=C:/MSYS/1.0/mingw/include;%INCLUDE% rem set LIB=C:/MSYS/1.0/lib;%LIB% if %2== set target=all if %2==build set target=all if %2==rebuild set target=clean all if %2==clean set target=clean echo Setting environment for Cygwin echo make.exe make -s -d %target% -f %1 The version of Make is $ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i686-pc-msys Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to bug-make@gnu.org. Paul D. Smith [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent by: Paul cc: bug-make@gnu.org Smith Subject: Re: 'fhandler_base::dup:' - Error [EMAIL PROTECTED] m 11/21/2005 05:24 PM Please respond to Paul D. Smith %% [EMAIL PROTECTED] writes: as I have been using MSYS-MINGW-GCC to compile and link my C++ code. as The problem I am having is following error. as Building GCCAltiaGui.exe as Executing: C:\Rhapsody6.1\Share\etc\cygwinmake.bat GCCAltiaGui.mak clean as Setting environment for Cygwin as make.exe as 0 [main] make 2772 fhandler_base::dup: dup(some disk file) failed, as handle 0, Win32 error 6 as Cleanup as Clean Done as This happens when I try to execute 'make' for the first time. The as version of 'make' is 3.79.1. Version of GCC is 3.2.3. The build as is on Windows 2000 machine. Hi; it looks like you are using the Cygwin-modified version of GNU make. That version of make is supported by the Cygwin team, not this mailing list (we support only the standard version of GNU make, provided on the FSF web site), for problems which seem likely to be related to Cygwin changes. if it's a generic problem with make of course you can ask here, but the above error looks very much to me like a system-specific error that would need to be addressed by the Cygwin team. I suggest you contact them. Good luck! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
