RE: not able start Dansguardian service

[Martin Dorey]

>From the evidence you have provided, it looks like you have a
pre-installed version of dansguardian that isn't working and that you've
successfully configured but not tried to build or install a version of
dansguardian from source.  If I were you, I'd be looking in
/var/log/messages or /var/log/syslog for any error message produced when
you try to start the dansguardian service, then googling for help with
that.  This mailing list won't be able to help you.  This mailing list
is for bugs in the make program.  There's no evidence of such a bug
here.

Good luck!
-
Martin's Outlook, BlueArc Engineering


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

RE: Need Help

[Martin Dorey]

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?

[Martin Dorey]

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:

  

___
  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

[Martin Dorey]

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

[Martin Dorey]

> 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

[bug #19035] Make recompiles source files eventhough the files are not modified

[Martin Dorey]

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:

  

___
  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: $(and) and $(or) not working

[Martin Dorey]

Works for me.  3.81 was released early in 2006 (the release note
(http://savannah.gnu.org/forum/forum.php?forum_id=4380) uses non-ISO
date format, so I'm unsure how to parse the month and day).  You'll want
to submit a minimally-sized example makefile with copy-and-pasted
output.  Like this:

[EMAIL PROTECTED]:/tmp$ cat > Makefile
$(error $(and 1))
[EMAIL PROTECTED]:/tmp$ make
Makefile:1: *** 1.  Stop.
[EMAIL PROTECTED]:/tmp$ cat > Makefile
$(error $(or 1))
[EMAIL PROTECTED]:/tmp$ make
Makefile:1: *** 1.  Stop.
[EMAIL PROTECTED]:/tmp$ 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 i486-pc-linux-gnu
[EMAIL PROTECTED]:/tmp$

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Noel
Yap
Sent: Wednesday, May 16, 2007 08:22
To: [EMAIL PROTECTED]; bug-make@gnu.org
Subject: $(and) and $(or) not working

I'm using the following:

yapn:[EMAIL PROTECTED]:~/proj/aoeu> make --version
GNU Make 3.81beta4
Copyright (C) 2003  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 i486-pc-linux-gnu


And the $(and) and $(or) functions always return empty.  Has anyone
else experienced this?

Thanks,
Noel


___
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 #19900] Target-specific variables not honored for rules generated by $(eval)

[Martin Dorey]

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:

  

___
  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 #20033] parallel (-j2) make with $(eval) construct segfaults

[Martin Dorey]

Follow-up Comment #2, bug #20033 (project make):

(I can reproduce a crash with that example.)


___

Reply to this item at:

  

___
  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: Problem with make...

[Martin Dorey]

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

RE: Single-suffix rules broken?

[Martin Dorey]

>   .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

[bug #21198] Wrong order of prerequisites with 3.81/CVS

[Martin Dorey]

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:

  

___
  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

[Martin Dorey]

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:

  

___
  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: canonicalization/stripping of leading ./

[Martin Dorey]

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=.:', and sometimes acceptable when 
'PATH=:.'; 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

RE: canonicalization/stripping of leading ./

[Martin Dorey]

> Its nice that the two are considered the same -- when we are
determining 
> dependencies.  It is not so nice when this changes the command line.

Yeah, "are canonicalized to be identical" is only one way of
implementing "are considered the same".  I think you've made a good case
for implementing it a different way but there may be counter-arguments.

...

Ah, and he who would know of said counter-arguments, and would have to
implement the different way agrees with you, saying (in one of the bugs
you mentioned):

https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=10708

>> $@, etc. should probably always be the exact target name, without any
of 
>> the internal translations performed

Paul's the maintainer, so you've a good chance of getting this behavior
changed.  It might, however, be a while.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, November 28, 2007 14:42
To: bug-make@gnu.org
Subject: RE: canonicalization/stripping of leading ./

On Wed, 28 Nov 2007, Martin Dorey wrote:

> 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.

Thanks for the link; I knew I'd read something like that before.


> It's helpful elsewhere that ./file and file are considered to be the
> same file.

Its nice that the two are considered the same -- when we are determining

dependencies.  It is not so nice when this changes the command line.

It still seems reasonable to expect that

cat <<_EOF > Makefile
test.out: $(srcdir)/script.sh
$< > $@
_EOF

should work in all cases -- not just when '.' is in $PATH or $(srcdir)
is 
other than '.'.  Though I guess

cat <<_EOF > Makefile
test.out: script.sh
$(srcdir)/$< > $@
_EOF

isn't too bad, now that I know to use it.

If it is decided that canonicalization of automatic variables is The
Right 
Thing(TM), then their section in the manual should probably be updated
to 
make that clear.  Having read that section a few times, I never guessed 
they were being filtered.
http://www.gnu.org/software/make/manual/html_node/Automatic-Variables.ht
ml

It would also be good to close the relevant bug reports as "invalid" or 
"won't fix" and leave a note as to the correct makefile syntax (e.g. use

$(srcdir) in the rules; not in the prerequisites).

Later,
Daniel


> -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=.:', and sometimes acceptable when
> 'PATH=:.'; 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

RE: install problem

[Martin Dorey]

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: make command

[Martin Dorey]

> 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
  
 

__
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: THIS PROGRAM BUILT FOR i686-pc-cygwin

[Martin Dorey]

> 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 3.81 crash: make: double free or corruption (!prev)

[Martin Dorey]

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: Reg Make build on LINUX

[Martin Dorey]

If you can reduce the test case makefiles to a few lines such that they
still demonstrate behavior that you can show is inconsistent with the
documentation, then we'd be very happy to help.  In that case, you'd
want to supply the makefiles and the output when you run make and any
instructions necessary to reproduce the problem.  Perhaps that would be
very hard.  We might be able to help with less work on your part but,
without any evidence, we aren't going to be able to help.  Given the
number of people using make compared to the number of people using your
makefiles, our assumption would have to be that the bug is in your
makefiles.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of A,
Sravanthi 
Sent: Friday, May 23, 2008 04:14
To: bug-make@gnu.org
Subject: Reg Make build on LINUX
Importance: High


Hi team,

Iam trying to build my application using make on Linux server. But my
build doesn't stop after first error. I tried -S options  but doesn't
seems to help.

I  have a makefile on parent folder and call makefiles in respective
subfolders for compiling. My LINUX machine is Red Hat Enterprise Linux
AS release 4 (Nahant Update 2) version. Same build stops on Solaris if
any error comes but not on Linux. Kindly help me or let me know in case
you need further details.

Thanks,


___
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: File timing bug

[Martin Dorey]

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 b>a
  b: c
  c: d
  date>b
  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
  date>b
  cp b c
  [EMAIL PROTECTED]:~/tmp/k$ make
  cat b>a
  [EMAIL PROTECTED]:~/tmp/k$

However, I noticed that if the Makefile looks like this:

  [EMAIL PROTECTED]:~/tmp/k$ cat Makefile
  a: b
  cat b>a
  b: c
  cp c b
  c: d
  date>c
  [EMAIL PROTECTED]:~/tmp/k$

Everything works as expected:

  [EMAIL PROTECTED]:~/tmp/k$ touch d
  [EMAIL PROTECTED]:~/tmp/k$ make
  date>c
  cp c b
  cat b>a
  [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+vista&mkt=en-US&form=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: File timing bug

[Martin Dorey]

(I know from experience that you have to tell make about when you update
targets that make knows about but I can't quote from the manual to
support that de jure.  (And I believe that the only way you can safely
update multiple targets from a single rule is if it's a Pattern Rule but
not a Static Pattern Rule.)  I was rather hoping I'd provoke a more
authoritative response from one of the real gurus but perhaps the
warnocking should be taken as agreement.)

-Original Message-
From: Herbert Euler [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 09, 2008 23:41
To: Martin Dorey; bug-make@gnu.org
Subject: 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.

Thank you for the information.  So I think it is Makefile.in from GNU
Automake that need modified for the expected behavior.  I'll write to
Automake's mailing list.

Regards,
Guanpeng Xu
_
Invite your mail contacts to join your friends list with Windows Live
Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.a
spx&mkt=en-us


___
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

[Martin Dorey]

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

[bug #23928] Add MAKEFILE variable

[Martin Dorey]

Follow-up Comment #1, bug #23928 (project make):

Simply add this to rules.mk and you're done:

MAKEFILE = $(firstword $(MAKEFILE_LIST))


___

Reply to this item at:

  

___
  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 #23928] Add MAKEFILE variable

[Martin Dorey]

> "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: dry-run (-n) has no effect with include file generation

[Martin Dorey]

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 
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

[Martin Dorey]

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 
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

[bug #24251] Random error including rebuilt makefiles

[Martin Dorey]

Follow-up Comment #1, bug #24251 (project make):

Looks like https://savannah.gnu.org/bugs/?102 to me.

___

Reply to this item at:

  

___
  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

[Martin Dorey]

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:

  

___
  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 report for "make" documentation

[Martin Dorey]

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." 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harald
Bergmann
Sent: Tuesday, October 07, 2008 07:10
To: bug-make@gnu.org
Subject: Bug report for "make" documentation


Dear developer,

at the PDF documentation of "make", which I currently loaded from your
web
side the following is found at top of page 25:

---
Wildcard expansion is performed by make automatically in targets and in
prerequisites.
In commands the shell is responsible for wildcard expansion. In other
contexts, wildcard
expansion happens only if you request it explicitly with the wildcard
function.
---

Some lines later at the lower half of the page there can be read:

---
Wildcard expansion does not happen when you define a variable. Thus, if
you
write this:
objects = *.o
then the value of the variable objects is the actual string '*.o'.
However,
if you use the
value of objects in a target, prerequisite or command, wildcard
expansion
will take place
at that time.
---

Even with the time relation told at the end both statements are
contradictory.

Probably the shell will expand as expected, but one can not be sure at
this
point. At least it will happen lately and not at "that time".

Many thanks for your great software!

Best regards,
Harald Bergmann


___
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

[Martin Dorey]

URL:
  

 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



___

Reply to this item at:

  

___
  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: possible bug in documentation for make

[Martin Dorey]

> 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 
Sent: Sat Oct 25 13:42:55 2008
Subject: possible bug in documentation for make

.

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

RE: make switch options

[Martin Dorey]

> 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: make --guaranteed-real-dry-run

[Martin Dorey]

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

[Martin Dorey]

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: Bug in make-3.81: variable_buffer moves out from under buffer

[Martin Dorey]

> 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

[Martin Dorey]

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  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

[Martin Dorey]

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  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

[Martin Dorey]

> 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: Minor documentation bug

[Martin Dorey]

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

[bug #25697] Segmentation fault setting .DEFAULT_GOAL

[Martin Dorey]

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: Error 127

[Martin Dorey]

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

RE: conditionals not working for conditional variables in sub-make?

[Martin Dorey]

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?

[Martin Dorey]

> 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 :
> 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?

[Martin Dorey]

> 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 :
>> 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?

[Martin Dorey]

(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 :
>> 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

[bug #27374] fatal error reading included makefile silently ignored

[Martin Dorey]

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:

  

___
  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: executing perl problem with make 3.81 versus 3.80

[Martin Dorey]

>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

RE: Splitting lines problem in make-3.80 versus 3.81

[Martin Dorey]

> 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: debian:/usr/src/dahdi-linux-2.2.0.2#

[Martin Dorey]

> 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  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

[bug #27437] Problems with make in a directory with present Makefiles. make does not function.

[Martin Dorey]

Follow-up Comment #3, bug #27437 (project make):

Neither makefile.am nor Makefile.in are usually makefiles.  makefile.am is,
as I understand it from eg the first google match for that file's name, used
to generate Makefile.in.  Makefile.in is used, as I understand it from eg the
second google match for that file's name, to generate Makefile.

___

Reply to this item at:

  

___
  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 #27809] several win64 fixes

[Martin Dorey]

> why can't you get rid of the cast altogether

Because there is no implicit conversion from pointer to integer.

> users of MinGW will then complain about compiler warnings, right?

Because of an implicit conversion from unsigned int (the definition of
uintptr_t on w32) to long, on a platform where both types are the same
size?  That seems unlikely.

-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Eli
Zaretskii
Sent: Monday, October 26, 2009 13:47
To: seze...@gmail.com; psm...@gnu.org; bo...@kolpackov.net;
bug-make@gnu.org
Subject: Re: [bug #27809] several win64 fixes

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

But you change pid_p to point to a pid_t type, which is no longer an
int on a 64-bit host.  So why can't you get rid of the cast
altogether, like this:

   pid_p = hProcess;

?  Does this work on w64?

> > 4. This change:
> >
> > -  pipedes[0] = _open_osfhandle((long) hChildOutRd, O_RDONLY);
> > +  pipedes[0] = _open_osfhandle((intptr_t) hChildOutRd, O_RDONLY);
> >
> > assumes that _open_osfhandle accepts an intptr_t type as its first
> argument.
> > But the prototype I have on my machine (in io.h) says the first
argument is
> a
> > `long'.  Which version of MinGW changed that?
> 
> It is the same case.  Your version is for w32-only.
> The mingw-w64 version is like (from io.h):
> _CRTIMP int __cdecl _open_osfhandle(intptr_t _OSFileHandle,int
_Flags);

But that means I cannot simply apply your patch, because users of
MinGW will then complain about compiler warnings, right?

Thanks for the other info.


___
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: issue when using MAKEFILES variable

[Martin Dorey]

I'm having trouble understanding what you mean.  When you've read my example 
below, if the lack of "hello from theconffile" output in the first run of make, 
and its presence in the second run, doesn't answer your question and show you 
how to solve the problem, then please modify my example to illustrate your 
problem, saying what you think the output should be where the actual output 
differs.

 

mart...@whitewater:~/tmp/make-jpm$ cat > theconffile

$(info hello from theconffile)

mart...@whitewater:~/tmp/make-jpm$ cat > Makefile

default:

^   MAKEFILES=theconffile $(MAKE) -C component -f Makefile

mart...@whitewater:~/tmp/make-jpm$ mkdir component

mart...@whitewater:~/tmp/make-jpm$ cat > component/Makefile

$(info hello from component/Makefile)

default:;

mart...@whitewater:~/tmp/make-jpm$ make

MAKEFILES=theconffile make -C component -f Makefile

hello from component/Makefile

make[1]: Entering directory `/home/martind/tmp/make-jpm/component'

make[1]: `default' is up to date.

make[1]: Leaving directory `/home/martind/tmp/make-jpm/component'

mart...@whitewater:~/tmp/make-jpm$ cat > Makefile

default:

^   MAKEFILES=$(CURDIR)/theconffile $(MAKE) -C component -f Makefile

mart...@whitewater:~/tmp/make-jpm$ make

MAKEFILES=/home/martind/tmp/make-jpm/theconffile make -C component -f Makefile

hello from theconffile

hello from component/Makefile

make[1]: Entering directory `/home/martind/tmp/make-jpm/component'

make[1]: `default' is up to date.

make[1]: Leaving directory `/home/martind/tmp/make-jpm/component'

mart...@whitewater:~/tmp/make-jpm$

 

-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of jean-luc malet
Sent: Friday, October 30, 2009 04:24
To: bug-make@gnu.org
Subject: issue when using MAKEFILES variable

 

hi!

I face issue when using MAKEFILES variable

this variable is set into a toplevel makefile and contain only

   export varname=varvalue

lines

 

then submake is called into rules like this

target :

  MAKEFILES=theconffile ${MAKE} -C the/component/path -f Makefile target

 

into the/component/path/Makefile

I have several include, some targets

and

$(warning ${VAR})

$(warning ${MAKEFILE_LIST})

$(warning ${MAKEFILES})

 

where VAR is a variable found only in theconffile

 

MAKEFILE_LIST and MAKEFILES warning show correct behaviour :

theconfile is first makefile read then Makefile is

VAR warning is correct, thus I think that the behaviour in correct

 

BUT all targets fails

there is a target todo: into the Makefile

and make complain about not knowing how to do todo

 

HOWEVER if I do

   include theconffile

into Makefile

and run sub make with

  ${MAKE} -C the/component/path -f Makefile target

 

then it works...

I'm puzzled

thanks a lot

JLM

 

-- 

KISS! (Keep It Simple, Stupid!)

(garde le simple, imbécile!)

"mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses

simples et qui marchent, espèce d'imbécile!"

-

"Si vous pensez que vous êtes trop petit pour changer quoique ce soit,

essayez donc de dormir avec un moustique dans votre chambre." Betty

Reese

http://www.grainesdechangement.com/citations.htm

 

 

___

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: issue when using MAKEFILES variable

[Martin Dorey]

> sadely I can't give you the real files

If you copy them, then strip out everything that turns out to be irrelevant, 
then rename all the remaining targets, variables and files, then you'll end up 
with an example that you can send us.  I've done that on a number of occasions 
for compiler bugs and, while I can attest that it's tedious work, it rarely 
takes longer than, say, an hour.

- Original Message -
From: jean-luc malet 
To: Martin Dorey
Cc: bug-make@gnu.org 
Sent: Sat Oct 31 12:24:45 2009
Subject: Re: issue when using MAKEFILES variable

Hi! thanks for the reply
I tried with another makefile created from scratch and indeed the
behaviour is the expected one...
the problem still arise with the makefile used in product
this makefile does include some other makefiles containing default rules
in fact this looks like this :

== Makefile.top 
include default.rules

SOURCES=1.c 2.c 3.c
todo : lib
== default.rules 
all : todo

some other rules that convert SOURCES variable into something usefull
=

when I add
include to Makefile.top this work each time (first and other times)
when I come back to the above and run it using MAKEFILES it never run
sadely I can't give you the real files because the files used are
owned by the corporation I'm working for...

I don't understand but it seems that the fact that make parse the
Makefile.top before the Makefile.conf and that make parse the
Makefile.conf before the Makefile.top change the behaviour

I was thinking about some ':=' variables but I don't think this is the issue
since Makefile.conf contain only export variable=values it can be
sourced into a sh when I do
source Makefile.conf; make -f Makefile.top all
this is working again

to summarise :
1) if I set the env before running make using sh this is working
2) if I use MAKEFILES variable to have make set the env for me this never work
3) if I use include directive in Makefile to have make set the env for
me it is working

for me 1) and 2) should behave the same way and for some reason it don't...
thanks and regard
JLM


On Fri, Oct 30, 2009 at 10:18 PM, Martin Dorey  wrote:
> I'm having trouble understanding what you mean.  When you've read my example
> below, if the lack of "hello from theconffile" output in the first run of
> make, and its presence in the second run, doesn't answer your question and
> show you how to solve the problem, then please modify my example to
> illustrate your problem, saying what you think the output should be where
> the actual output differs.
>
>
>
> mart...@whitewater:~/tmp/make-jpm$ cat > theconffile
>
> $(info hello from theconffile)
>
> mart...@whitewater:~/tmp/make-jpm$ cat > Makefile
>
> default:
>
> ^   MAKEFILES=theconffile $(MAKE) -C component -f Makefile
>
> mart...@whitewater:~/tmp/make-jpm$ mkdir component
>
> mart...@whitewater:~/tmp/make-jpm$ cat > component/Makefile
>
> $(info hello from component/Makefile)
>
> default:;
>
> mart...@whitewater:~/tmp/make-jpm$ make
>
> MAKEFILES=theconffile make -C component -f Makefile
>
> hello from component/Makefile
>
> make[1]: Entering directory `/home/martind/tmp/make-jpm/component'
>
> make[1]: `default' is up to date.
>
> make[1]: Leaving directory `/home/martind/tmp/make-jpm/component'
>
> mart...@whitewater:~/tmp/make-jpm$ cat > Makefile
>
> default:
>
> ^   MAKEFILES=$(CURDIR)/theconffile $(MAKE) -C component -f Makefile
>
> mart...@whitewater:~/tmp/make-jpm$ make
>
> MAKEFILES=/home/martind/tmp/make-jpm/theconffile make -C component -f
> Makefile
>
> hello from theconffile
>
> hello from component/Makefile
>
> make[1]: Entering directory `/home/martind/tmp/make-jpm/component'
>
> make[1]: `default' is up to date.
>
> make[1]: Leaving directory `/home/martind/tmp/make-jpm/component'
>
> mart...@whitewater:~/tmp/make-jpm$
>
>
>
> -Original Message-
> From: bug-make-bounces+mdorey=bluearc@gnu.org
> [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of jean-luc
> malet
> Sent: Friday, October 30, 2009 04:24
> To: bug-make@gnu.org
> Subject: issue when using MAKEFILES variable
>
>
>
> hi!
>
> I face issue when using MAKEFILES variable
>
> this variable is set into a toplevel makefile and contain only
>
>    export varname=varvalue
>
> lines
>
>
>
> then submake is called into rules like this
>
> target :
>
>   MAKEFILES=theconffile ${MAKE} -C the/component/path -f Makefile
> target
>
>
>
> into the/component/path/Makefile
>
> I have several include, some targets
>
> and
>
> $(war

RE: not a bug but some strange behaviour

[Martin Dorey]

Can you contrive a simple test case - something that you can post here in its 
entirety to help someone reproduce the problem?

-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of jean-luc malet
Sent: Monday, November 30, 2009 10:27
To: bug-make
Subject: not a bug but some strange behaviour

Hi!
I have a cygwin environment in which I've written a makefile, in this
environment it's working fine
I want to make it available to other dos user, so I've written a bat
file that set the cygwin path and call make,
in the doc env when I do
echo %somevar%
I see the correct result
however in commands launched by make (shell scripts) the ${somevar}
expand to nothing... as if make was stripping the env
any idea?
thanks
JLM

-- 
KISS! (Keep It Simple, Stupid!)
(garde le simple, imbécile!)
"mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses
simples et qui marchent, espèce d'imbécile!"
-
"Si vous pensez que vous êtes trop petit pour changer quoique ce soit,
essayez donc de dormir avec un moustique dans votre chambre." Betty
Reese
http://www.grainesdechangement.com/citations.htm


___
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: not a bug but some strange behaviour

[Martin Dorey]

> $make.bat test3

> 



Interestingly, I failed to reproduce your problem:



$ ./make.bat test3



C:\Documents and Settings\martind\playpen\jlm-2009-11-30>C:\cygwin-1.5\bin\make 
test3

printf "${ENV_VAR1}\n"

fromtheenv

$



I tried with Cygwin 1.5 and 1.7.  Here's more information about the 1.5 
versions:



$ uname -a

CYGWIN_NT-5.1 vm-martind 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

$ bash --version

GNU bash, version 3.2.49(22)-release (i686-pc-cygwin)

Copyright (C) 2007 Free Software Foundation, Inc.

$ 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 i686-pc-cygwin

$



The exact test case I used wasn't quite the same as you gave:



$ cat make.bat

C:\cygwin-1.5\bin\make %*

$ cat Makefile



export TEST_FLAG=test

SHELL=/bin/bash



test :

printf "$${TEST_FLAG}\n"



test2 :

printf "${TEST_FLAG}\n"



test3 :

printf "$${ENV_VAR1}\n"



test4 :

printf "${ENV_VAR1}\n"



test5 :

ENV_VAR1=${ENV_VAR1}; /bin/bash somescriptthatdoprintfenv_var1





$



If I had make.bat run "make", then it ended up invoking itself.  My bat-fu is 
weak:



$ cat make.bat

set PATH=C:\cygwin-1.5\bin;%PATH%

make %*

$



-Original Message-
From: jean-luc malet [mailto:jeanluc.ma...@gmail.com]
Sent: Monday, November 30, 2009 14:27
To: Martin Dorey
Cc: bug-make
Subject: Re: not a bug but some strange behaviour



$cat make.bat

set PATH=cygwin_Path;oldPath

make %*



$ cat /tmp/Makefile



export TEST_FLAG=test

SHELL=/bin/bash



test :

 printf "$${TEST_FLAG}\n"



test2 :

 printf "${TEST_FLAG}\n"



test3 :

 printf "$${ENV_VAR1}\n"



test4 :

 printf "${ENV_VAR1}\n"



test5 :

 ENV_VAR1=${ENV_VAR1}; /bin/bash somescriptthatdoprintfenv_var1







$ export ENV_VAR1=fromtheenv

- cygwin env (make is called throught a .bat file) -

$ make.bat test



$ make.bat test2

test

$make.bat test3



$make.bat test4

fromtheenv

$make.bat test5

fromtheenv



-- from an interactive shell, cygwin env 

$make test

test

$make test2

test

$make test3

fromtheenv

$make test4

fromtheenv

$make test5

fromtheenv



--- linux --

always working



to make it short : if you call the subshell by setting the env

variable on the same line it will ever work

if you try to access some env variable in the makefile it always work

if you try to use the env variable into one of the command it fails

depending on the context.



Best Regards

JLM



On Mon, Nov 30, 2009 at 8:22 PM, Martin Dorey  wrote:

> Can you contrive a simple test case - something that you can post here in its 
> entirety to help someone reproduce the problem?

>

> -Original Message-

> From: bug-make-bounces+mdorey=bluearc@gnu.org 
> [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of jean-luc 
> malet

> Sent: Monday, November 30, 2009 10:27

> To: bug-make

> Subject: not a bug but some strange behaviour

>

> Hi!

> I have a cygwin environment in which I've written a makefile, in this

> environment it's working fine

> I want to make it available to other dos user, so I've written a bat

> file that set the cygwin path and call make,

> in the doc env when I do

> echo %somevar%

> I see the correct result

> however in commands launched by make (shell scripts) the ${somevar}

> expand to nothing... as if make was stripping the env

> any idea?

> thanks

> JLM

>

> --

> KISS! (Keep It Simple, Stupid!)

> (garde le simple, imbécile!)

> "mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses

> simples et qui marchent, espèce d'imbécile!"

> -

> "Si vous pensez que vous êtes trop petit pour changer quoique ce soit,

> essayez donc de dormir avec un moustique dans votre chambre." Betty

> Reese

> http://www.grainesdechangement.com/citations.htm

>

>

> ___

> Bug-make mailing list

> Bug-make@gnu.org

> http://lists.gnu.org/mailman/listinfo/bug-make

>







--

KISS! (Keep It Simple, Stupid!)

(garde le simple, imbécile!)

"mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses

simples et qui marchent, espèce d'imbécile!"

-

"Si vous pensez que vous êtes trop petit pour changer quoique ce soit,

essayez donc de dormir avec un moustique dans votre chambre." Betty

Reese

http://www.grainesdechangement.com/citations.htm
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

debian/stamp/build/kernel) Fehler2

[Martin Dorey]

Perhaps the 2 corresponds to ENOENT, which means that a name wasn't found in a 
directory.



mart...@whitewater:~/work/tiger$ sgrep ENOENT /usr/include/asm-generic

/usr/include/asm-generic/errno-base.h:5:#define ENOENT2/* No 
such file or directory */

mart...@whitewater:~/work/tiger$



The first sign of failure is usually the most enlightening.  In the universe of 
build failures, there's usually some error message before make's *** line.  (I 
can't speak to make-kpkg errors.)



There doesn't seem any evidence of a make bug here.



-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of "Günther 
Hüttemann"
Sent: Wednesday, December 23, 2009 06:04
To: bug-make@gnu.org
Subject: (no subject)





make: *** (debian/stamp/build/kernel) Fehler2 (mistake 2)





This came on the screen at the end, after I started:



CONCURRENCY_LEVEL=N fakeroot make-kpkg --initrd --append-to-version=-custom 
kernel_image kernel_headers



as "make" is installed "make 3.81-6"



how can I understand this massage?



with kind regards



Guenther Huettemann

--

GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!

Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01





___

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: Weird text-dependent bug in $(eval ...), simple test case

[Martin Dorey]

> (b) the messages are only produced for some words

That's not the case for me, with Debian Lenny's 3.81.

mart...@whitewater:~/tmp$ dpkg -S `which make`
make: /usr/bin/make
mart...@whitewater:~/tmp$ dpkg --status make
...
Version: 3.81-5
...
mart...@whitewater:~/tmp$ make -f buggyMakefile 
buggyMakefile:2: target `normal' given more than once in the same rule.
buggyMakefile:2: target `c99-pedantic' given more than once in the same rule.
buggyMakefile:2: target `c89-pedantic' given more than once in the same rule.
buggyMakefile:2: target `foobar' given more than once in the same rule.
buggyMakefile:2: target `baz' given more than once in the same rule.
make: `normal' is up to date.
mart...@whitewater:~/tmp$

>GNU MAke 3.81

That capital A... surely not a hardware fault?

-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Jamie Lokier
Sent: Wednesday, February 10, 2010 12:41
To: bug-make@gnu.org
Subject: Weird text-dependent bug in $(eval ...), simple test case

Dear Make maintainers,

Create a file called buggyMakefile with these two lines:

CONFIGS := normal c99-pedantic c89-pedantic foobar baz
$(foreach C,$(CONFIGS),$(eval $C $C/:;))

and then run "make -f buggyMakefile".

If you're using the same GNU Make 3.81 as me, it will greet you with
some surprising messages:

buggyMakefile:2: target `c99-pedantic' given more than once in the same rule.
buggyMakefile:2: target `foobar' given more than once in the same rule.
buggyMakefile:2: target `baz' given more than once in the same rule.
make: `normal' is up to date.

It's surprising because (a) there shouldn't be those "more than once"
messages at all (the forward-slash makes them different targets), and
(b) the messages are only produced for some words, not others.  It
depends on the words, not the order in the list.

It is dependent on the characters in the words.  If the words
"normal" and "c89-pedantic" are changed to something else, even with
the same length, they show up in the "more than once" errors.

This bug was found with the "make-3.81-6" package distributed with
32-bit x86 Ubuntu 9.10 (Karmic Koala), which should be plain GNU Make 3.81.
Output of "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 i486-pc-linux-gnu

Thanks,
-- Jamie


___
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: Weird text-dependent bug in $(eval ...), simple test case

[Martin Dorey]

> completely reproducible without using $(eval)!

"How", I wondered to myself, "is Philip defining multiple rules in one line 
without using $(eval)?".  Eventually, I realized that the essence of one of the 
OP's allegations - the one we can reproduce - is that this, much simpler test 
case, demonstrates a bug:

mart...@whitewater:~/playpen$ cat buggyMakefile 
normal normal/:;
mart...@whitewater:~/playpen$ make -f buggyMakefile 
buggyMakefile:1: target `normal' given more than once in the same rule.
make: `normal' is up to date.
mart...@whitewater:~/playpen$

> if you could examine why this happened in this case

I bet the other allegation - about text-dependent errors - doesn't happen 
without $(eval).  I wonder what was behind that issue, which neither Paul nor I 
reproduced.

>> both of you see buggy behaviour

I'm hoping someone will say "that's by-design for ".  Then 
the OP can say "OK, not a bug, but a design error", bringing us to an impasse 
where we can drop the matter.

-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Philip 
Guenther
Sent: Sunday, February 28, 2010 22:41
To: Jamie Lokier
Cc: bug-make@gnu.org
Subject: Re: Weird text-dependent bug in $(eval ...), simple test case

On Sun, Feb 28, 2010 at 6:25 PM, Jamie Lokier  wrote:
> Both of you have confirmed the bug - because the correct behaviour has
> no error messages, and you both got messages.  Neither of you was able
> to reproduce getting a text-dependent number of messages, but both of
> you see buggy behaviour so it's easy to reproduce a problem to investigate.
>
> Nobody wants to investigate this bug further?

Not to make an insane suggestion, but have you considered filing a bug
in the GNU bug tracking system, Savannah?
http://savannah.gnu.org/projects/make/

As a side note, I don't understand why you call this a bug in
$(eval)...as it's completely reproducible without using $(eval)!  Did
you try testing it directly?  If not, why not?

We've seen this on the list now multiple times: it seems that if
someone first encounters a bug while working with $(eval), they report
the problem as being in $(eval) and make no attempt to reproduce it
directly.  Since this is a hinderance to getting good bug reports, it
would help if you could examine why this happened in this case so that
it might possible be avoided in the future with others.


Philip Guenther


___
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 manual update

[Martin Dorey]

> What's the most recent edition;

@set EDITION 0.70
@set RCSID $Id: make.texi,v 1.64 2009/11/12 16:42:36 bosk Exp $

> where can I find an authoritative copy ?

http://cvs.savannah.gnu.org/viewvc/make/doc/make.texi?revision=HEAD&root=make&view=markup

Instructions for setting up a Cvs work area are at:

http://savannah.gnu.org/cvs/?group=make

-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Edward 
Welbourne
Sent: Sunday, February 28, 2010 05:07
To: bug-make@gnu.org
Subject: Make manual update

Hi GNU make maintainers,

I began work on some additions and refinements to make.texi fourteen months ago 
but got
distracted.  The version I started from has
@set EDITION 0.70
@set RCSID $Id: make.texi,v 1.45 2006/04/01 06:36:40 psmith Exp $
What's the most recent edition; and where can I find an authoritative copy ?

I currently have my changes in a git repository, from which I can
extract patches as needed - but if submitting it in the form of (a link
to somewhere from which you can download) a tarred-up git repo is a
usable format for you, that would be easy to do - once I've re-based
onto a more up-to-date version.

Eddy.


___
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: Static multiple target rules

[Martin Dorey]

> instead of a touch-file, use a tar-file !

Yeah, one of my company's makefiles uses a similar intermediate file to good 
effect.  We've been using the touch-file or "sentinel" solution elsewhere for 
years.  I'd previously suggested replacing the sentinels with tar files so we 
could get rid of all the hackery we have to address the problem Tom raised 
about non-existent targets.  We have a macro that's used to convert missing 
source file names to the name of the corresponding sentinel file and then code 
to force that sentinel to rebuild.  It's complicated, ugly and fragile.

What really motivated me to reply, however, was:

> Note the crucial -m in the extracting tar

I would have made that mistake, so thanks for pointing it out before I stepped 
on the rake!

-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Edward 
Welbourne
Sent: Tuesday, March 02, 2010 02:45
To: tom honermann
Cc: bug-make@gnu.org
Subject: Re: Static multiple target rules

> I've been struggling for some time now with how to write rules for 
> commands that generate multiple targets

A familiar and annoying problem: make really believes in commands that
generate just one (relevant) file, and doesn't fit so well with ones
that generate several.

> The next thing to try is using a proxy or timestamp file:
>
>yacc.ts: grammar.y
>yacc -d -v $^
>touch $@
>
>y.tab.h y.tab.c y.output: yacc.ts

A quarter of an hour after reading your mail, I had a mildly perverted
idea: instead of a touch-file, use a tar-file !  The problem you point
to is when the touch file exists but the files we want don't: we need
a command for the rule that declares their dependency on it; and that
command needs to be able to generate the outputs from the fake file.

yacc.ts: grammar.y
yacc -d -v $^
tar cf $@ y.tab.h y.tab.c y.output

y.tab.h y.tab.c y.output: yacc.ts
tar xf $< -m

Note the crucial -m in the extracting tar, so that we touch the
outputs after the tar-file has been created, thereby avoiding
re-extracting every time we run make.

Not sure how well that'd work but it *looks* like it should ... and it
should generalise reasonably well.  Unfortunately I can't, just yet,
see how to turn it into a pattern rule for general .y file processing,

Eddy.


___
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

[Martin Dorey]

That isn't a problem with a makefile. That's a problem with main.cpp. I might 
guess that you should try changing iostream.h to iostream but that's only a 
guess out of goodwill. This mailing list isn't for helping with C++ problems. I 
don't know where you can turn for help. Perhaps wherever you got main.cpp from.


From: bug-make-bounces+mdorey=bluearc@gnu.org 

To: bug-make@gnu.org 
Sent: Sun Apr 11 05:46:17 2010
Subject: Bug

Hello everybody,
I have a problem with makefile. When I type make, the result is:
-
tig...@tigran-laptop:~/Documents/MakeFile/sample$ make
g++ main.cpp hello.cpp factorial.cpp -o hello
main.cpp:1:22: error: iostream.h: No such file or directory
main.cpp: In function ‘int main()’:
main.cpp:6: error: ‘cout’ was not declared in this scope
main.cpp:6: error: ‘endl’ was not declared in this scope
hello.cpp:1:22: error: iostream.h: No such file or directory
hello.cpp: In function ‘void print_hello()’:
hello.cpp:5: error: ‘cout’ was not declared in this scope
make: *** [all] Error 1
-
Could you help me.
Thanks.
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

RE: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

[Martin Dorey]

>> If an update to new source code, that would compile just fine in a clean 
>> checkout, breaks the incremental build, the build system is errornuous.

> I would like to agree with you, but this constraint is, in general,
> incompatible with incremental building

That's a entertainingly provocative claim.  I'm not convinced that it's been 
demonstrated and, further, I don't believe it to be true.  Where we parted 
company was here:

>>> Speaking of the subtleties of dependency tracking: do an update in
>>> your version control system, watch some header go away - and all files
>>> that used to reference it drop those references.  Your .d files claim
>>> a bunch of stuff depends on this missing file; but you have no rule to
>>> regenerate it.

You don't need to regenerate it.  In a make-using system that I maintain, but 
am not allowed to share with you (which was why I bit my tongue earlier - not 
very public-spirited of me), there's a .DEFAULT rule, which essentially does:

echo Pretending to have generated $@ 1>&2

Now, lying to the computer, like I am there, often doesn't end well.  Having a 
default target that claims to be able to build anything, if that's what I had, 
would cause pain when debugging the makefiles.  There may be other aspects of 
the system I'm using, which I haven't shared and perhaps am not even aware of, 
which are saving me from falling into trouble due to these caveats.  However, 
in my experience and opinion, these issues are not as serious as losing 
incremental building.

-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Edward 
Welbourne
Sent: Thursday, April 29, 2010 08:00
To: Robert Jørgensgaard Engdahl
Cc: bug-make@gnu.org
Subject: Re: Shorter and less error-prone rule for automatic prerequisite 
generation in the GNU Make manual

> If an update to new source code, that would compile just fine in a clean 
> checkout, breaks the incremental build, the build system is errornuous.

I would like to agree with you, but this constraint is, in general,
incompatible with incremental building, which is too good a benefit to
throw away.

> Anything that seeks to fix such bugs by user intervention is not a real
> solution. At least that is my opinion. I just don't know how that could be
> solved nicely in Make.

Quite.  In the mean time, we get as close to this ideal as possible
and we have clean-rules to purge selective chunks of what incremental
building normally caches for us, to deal with the messy cases.

If people *routinely need* to use any clean rule in the course of
their normal work-flows, I consider the build system inadequate: but
I'll still include clean rules for use when the exceptional situations
do come up (and as an aid to debugging).

Eddy.


___
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 #30105] Recipes defined for special targets like .SUFFIXES are silently ignored: make should warn about them

[Martin Dorey]

Follow-up Comment #2, bug #30105 (project make):

So ifeq (yes, yes) counts a "a blank line" because it evaluates to nothing? 
"a blank line" would be consistent with "next line that does not begin with a
TAB", so that wording's not optimal.  "next line that begins with something
other than a TAB" might be OK but the subtle distinction would be lost on most
readers, me included.  This is news to me (well, apart from the SUFFIXES bit)
and I'm not seeing a clear explanation of it in the manual (3.81 or CVS).

___

Reply to this item at:

  

___
  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 #30105] Recipes defined for special targets like .SUFFIXES are silently ignored: make should warn about them

[Martin Dorey]

Follow-up Comment #4, bug #30105 (project make):

(That explanation is clear, thanks.  That'll teach me to search for TAB in
capitals, as is used sometimes elsewhere in the manual.)

___

Reply to this item at:

  

___
  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: Installing GoogleEarth

[Martin Dorey]

You typed a space instead of a hyphen after "make".

sudo make-googleearth-package --force
sudo make googleearth-package --force

Don't blush. If only all bug reports were so complete.


From: bug-make-bounces+mdorey=bluearc@gnu.org 

To: bug-make@gnu.org 
Sent: Fri Jul 09 09:51:35 2010
Subject: Installing GoogleEarth

Trying to install GE on a quadCore Intel machine running Lucid Lynx as per:
http://www.techdrivein.com/2010/06/install-google-earth-in-ubuntu-1004.html
I get an error  which i was not expecting do I have the wrong hardware for the 
installation).
Upon issuing the command:
sudo make googleearth-package --force
I get:
make: unrecognized option '--force'



--
Gregor Shapiro
Lasarettsvägen 11
SE 302 33 Halmstad Sweden
0046 (0)73 976 2989
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

RE: source file extension

[Martin Dorey]

> define assert
> $(call assert,$($ARGS), The variable "$ARGS" is null)
> endef

This code is dead - nothing calls it.  I see that it includes an expression 
that will be evaluated (if it's ever called) as $(A)RGS when it was probably 
intended to say $(ARGS).

> SRCS = $(wordlist 2, 999, $(ARGS))

What sets ARGS?  Not make:

mart...@whitewater:/tmp$ make -f badger.make -p 2>&1 | grep ARGS
mart...@whitewater:/tmp$ 

Putting spaces after commas helps readability but it's generally a bad idea in 
makefiles.  It's semantically significant:

mart...@whitewater:/tmp$ cat > badger.make
SRCS := $(subst a, b, bac)
mart...@whitewater:/tmp$ make -f badger.make -p 2>&1 | grep SRCS
SRCS :=  b bc
mart...@whitewater:/tmp$ 

> $(EXEC-FILE): $(SRCS:%.o=%.mod)
> # $(LINK) $@ $^   
>$(LINK) $^ -o $@

The first line after the colon must start with a tab.  Perhaps it does already 
but something bad happened to that rule, perhaps in transit, likely from my 
mail client (sorry).

Now, sigh, this is going to sound patronising, for which I apologize, but 
hopefully you'll appreciate that more than just going silent on you:

Bug reports should show what you typed and what the computer displayed.  It 
would also be a good idea to include which version of make you're using and 
ideally on which platform.  This mailing list is really for bugs in Make 
itself, not for bugs in makefiles.  I believe there's a help-make list for that.

-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Duke Normandin
Sent: Wednesday, October 20, 2010 15:21
To: Paul Smith
Cc: Bug-make@gnu.org
Subject: Re: source file extension

On Wed, 20 Oct 2010, Paul Smith wrote:

> On Wed, 2010-10-20 at 16:08 -0600, Duke Normandin wrote:
> > %.o:%.mod
> >$(MODULA) %<
>
> This should be "$<", not "%<".

I should use my "good eye" when I program and debug! Thanks for
catching that. Unfortunately fixing the typo didn't solve the
problem. Any other ideas?
-- 
Duke

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make


-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Duke Normandin
Sent: Wednesday, October 20, 2010 15:09
To: Bug-make@gnu.org
Subject: source file extension

Hello list...

I recently cobbled together a "generic" Makefile for an Oberon-2
compiler - with the help of 2 generous hackers on this list. Works
great with Oberon.

Today I tried the same Makefile with a Modula-2 compiler, after making
the necessary changes. The Modula compiler is really a gcc
front-end. It behaves pretty much like the Oberon compiler. However,
the Makefile doesn't seem to want to create the object file when used
for the Modula-2 compiler. The Modula-2 source code file extension is
".mod", as opposed to a single-char extension, like .c, or .m . Could
that be the problem? Here's the relevant code:

define assert
$(call assert,$($ARGS), The variable "$ARGS" is null)
endef

# save CLI arguments
   EXEC-FILE = $(word 1, $(ARGS))   
  SRCS = $(wordlist 2, 999, $(ARGS))

LINK = gm2  
   MODULA = gm2 -c
$(EXEC-FILE): $(SRCS:%.o=%.mod)
# $(LINK) $@ $^ 
 $(LINK) $^ -o $@
%.o:%.mod
   $(MODULA) %<
Much obliged!   
   --
Duke

___
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 #31361] MinGW make inexplicably invokes as.exe

[Martin Dorey]

Follow-up Comment #8, bug #31361 (project make):

If your bug isn't in make, then it doesn't belong in make's bug database,
under any name.

___

Reply to this item at:

  

___
  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 #31361] MinGW make inexplicably invokes as.exe

[Martin Dorey]

Follow-up Comment #11, bug #31361 (project make):

> I just thought a more appropriate name might help others in my position

And it might well do.  (I too can't see how to change the name.)  I just
feared that you were hoping that someone would look at a gcc issue here.

>  could you point me towards the right bug database for g++ and cc1plus?

http://gcc.gnu.org/bugzilla/ perhaps, although, if it's MinGW-specific, I
fear they won't care too much and might even turn you away. 
http://www.mingw.org/Reporting_Bugs has some suggestions and even invites
mailing list postings in a friendly fashion.

___

Reply to this item at:

  

___
  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 #32247] ../make/main.c:534: error: static declaration of ‘bsd_signal’ follows non-static declaration

[Martin Dorey]

URL:
  

 Summary: ../make/main.c:534: error: static declaration of
‘bsd_signal’ follows non-static declaration
 Project: make
Submitted by: mdorey
Submitted on: Tue 25 Jan 2011 09:20:18 PM GMT
Severity: 3 - Normal
  Item Group: Build/Install
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: CVS
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

On my run-of-the-mill Debian Lenny system:

martind@whitewater:~/download/make-cvs/whitewater2$ uname -a
Linux whitewater 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64
GNU/Linux
martind@whitewater:~/download/make-cvs/whitewater2$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-cld --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1) 
martind@whitewater:~/download/make-cvs/whitewater2$ 

The build from clean, from CVS, fails at:

../make/main.c:534: error: static declaration of ‘bsd_signal’ follows
non-static declaration
/usr/include/signal.h:109: error: previous declaration of ‘bsd_signal’
was here
../make/main.c: In function ‘main’:
../make/main.c:1872: warning: comparison of unsigned expression < 0 is always
false
../make/main.c:2209: warning: comparison of unsigned expression < 0 is always
false
make[2]: *** [main.o] Error 1

The conftest results in:

configure:8605: checking whether bsd_signal is declared
configure:8635: gcc -c -g -O2  conftest.c >&5
conftest.c: In function 'main':
conftest.c:76: error: 'bsd_signal' undeclared (first use in this function)
conftest.c:76: error: (Each undeclared identifier is reported only once
conftest.c:76: error: for each function it appears in.)

config.log says the program being compiled is:

| /* end confdefs.h.  */
| #include 
| 
| int
| main ()
| {
| #ifndef bsd_signal
|   (void) bsd_signal;
| #endif
| 
|   ;
|   return 0;
| }

If, however, I try to compile that program, or something very similar, with
an extra macro:

#define _GNU_SOURCE 1
#include 

int main() {
(void) bsd_signal;
}

Then it succeeds.  make.h defines this macro before including signal.h:

/* Specify we want GNU source code.  This must be defined before any
   system headers are included.  */

#define _GNU_SOURCE 1
...
#include 

Searching for bsd_signal here, I see this changed not too long ago, under:

bug #25713: Please note CPPFLAGS required to build on Tru64

After Google pointed me to
http://www.airs.com/ian/configure/configure_2.html, specifically the mention
of how to define _GNU_SOURCE in autoconf, I tried the attached patch, which
seemed to work for me.  I have no idea what I'm doing with autoconf.  Perhaps
the macro should be defined earlier in configure.in.



___

File Attachments:


---
Date: Tue 25 Jan 2011 09:20:18 PM GMT  Name: bsd_signal.patch  Size: 636B  
By: mdorey
a configure.in patch which defines _GNU_SOURCE before the bsd_signal test


___

Reply to this item at:

  

___
  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 #33134] spurious error when stdout is already closed

[Martin Dorey]

> maybe there's a better way of checking for closure than ftell

http://software.jessies.org/svn/salma-hayek/trunk/native/all/ruby-launcher/ruby-launcher.cpp
 suggests:

// This might look obscure but the man page suggests that it's a 
POSIX-compliant way
// of testing whether a file descriptor is open.
int rc = fcntl(targetFd, F_GETFL);
if (rc != -1) {
return;
}
if (errno != EBADF) {

Unlike make, that code only needs to worry about POSIX.  I quote it mainly, 
then, to suggest that doing this portably might prove surprisingly hard.  It 
would be portable and, if David's plausible explanation is right, more 
intention-revealing, but more complicated and less efficient, to keep track of 
whether stdout has ever been written to, and only close it then.

-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of David Boyce
Sent: Wednesday, April 20, 2011 21:32
To: Philip Guenther
Cc: bug-make
Subject: Re: [bug #33134] spurious error when stdout is already closed

On Thu, Apr 21, 2011 at 12:00 AM, Philip Guenther  wrote:
> Why is that a mistake?
>
> It appears you're saying that make should complain about failures to
> write to stdout for reasons like EIO, ENOSPC,  and EOVERFLOW, but
> *not* for EBADF.

I think you're still not getting my point here. I do not believe this
has anything to do with *writes* at all, failed or otherwise. Make is
attempting to close something that's already closed and complaining
when it doesn't work. POSIX is quite clear that fclose on a closed
stream results in an error condition.

> (Actually, your patch doesn't just ignore EBADF errors: it ignores
> EPIPE errors, as the ftell() will fail on the pipe.  Why is that a
> good idea?)

You're right on this. An earlier version of my change, when it was
implemented within close_stdout(), looked something like

if (ftell(stdout) == -1 && errno == EBADF) ...

but I lost the EBADF test when I redid it. That was a mistake, and
maybe there's a better way of checking for closure than ftell anyway,
but the basic point of not closing something unless it was open
remains.

David B

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

$(sort) - what is "lexical order"? (was RE: Follow-up)

[Martin Dorey]

OP has something of a point: contrast the locale-dependent behavior of sort(1) 
with make's $(sort):

$ echo 'L:=$(sort B a)' | make -f - -p 2>&1 | grep '^L '
L := B a
$ { echo B; echo a; } | sort
a
B
$ { echo B; echo a; } | LC_ALL=C sort
B
a
$

I present this more to provoke "we can't change that!" and clarified 
documentation than as a serious suggestion:

Index: configure.in
===
RCS file: /sources/make/make/configure.in,v
retrieving revision 1.157
diff -u -r1.157 configure.in
--- configure.in29 Aug 2010 23:05:27 -   1.157
+++ configure.in 12 Jul 2011 21:11:28 -
@@ -166,6 +167,7 @@
 AC_CHECK_FUNCS(strcasecmp strncasecmp strcmpi strncmpi stricmp strnicmp)

 # strcoll() is used by the GNU glob library
+# and by $(sort)
 AC_FUNC_STRCOLL

 AC_FUNC_ALLOCA
Index: misc.c
===
RCS file: /sources/make/make/misc.c,v
retrieving revision 1.84
diff -u -r1.84 misc.c
--- misc.c  6 Nov 2010 21:56:24 -  1.84
+++ misc.c   12 Jul 2011 21:11:28 -
@@ -51,6 +51,10 @@
 # define VA_END(args)
 #endif

+#if !defined(HAVE_STRCOLL)
+# define strcoll strcmp
+#endif
+

 /* Compare strings *S1 and *S2.
Return negative if the first is less, positive if it is greater,
@@ -62,9 +66,7 @@
   const char *s1 = *((char **)v1);
   const char *s2 = *((char **)v2);

-  if (*s1 != *s2)
-return *s1 - *s2;
-  return strcmp (s1, s2);
+  return strcoll (s1, s2);
 }

 /* Discard each backslash-newline combination from LINE.
cvs diff: Diffing config
cvs diff: Diffing doc
Index: doc/make.texi
===
RCS file: /sources/make/make/doc/make.texi,v
retrieving revision 1.72
diff -u -r1.72 make.texi
--- doc/make.texi2 May 2011 15:11:23 - 1.72
+++ doc/make.texi 12 Jul 2011 21:11:28 -
@@ -6846,6 +6846,8 @@

 @noindent
 returns the value @samp{bar foo lose}.
+In a change from previous versions, make now sorts in locale-dependent order.
+Run with LC_ALL=C in the environment to select the previous behavior.

 @cindex removing duplicate words
 @cindex duplicate words, removing


From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Rob Holbert
Sent: Monday, July 11, 2011 12:24
To: bug-make@gnu.org
Subject: Follow-up

Wanted to followup to my earlier email. Attached is the smallest makefile I 
could create to demonsterate the issue.

or

#does not sort lexically like expected
LIST = $(sort widget.c main.c ad.c Buzzer.c)
#target
all: list
list:
@echo $(LIST)
.PHONY: all list

Previous email:
Hello,

I ran across perhaps a bug or need for another feature at least. If a list of 
items has words beginning with both upper and lower case letters, the resulting 
$(sort $(LIST)) will result in all capital letter words coming before the lower 
case words. In this case, Zebra.c would appear before apple.c. This is dictated 
by the ASCII chart of course. However, it is not lexical order as the manual 
explains the function is. Lexical would be apple.c Zebra.c.

This is solved easily by making the sort comparison convert all alphas to lower 
case before comparing, leaving the original string case unchanged.

I like to use sort to put my sources in order. This way it is easier to see if 
an object file is missing for instance.

Best Regards,
Rob
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: $(sort) - what is "lexical order"? (was RE: Follow-up)

[Martin Dorey]

If I had check-in privs, I'd at least make this issue explicit in the 
documentation.  Even that, though, will require others on the list to be 
persuaded.

> Maybe $(alphabetize )?

Creative, but the name doesn't really work for writing systems, like Mandarin 
written in hanzi, without an alphabet.

Did you realize that your makefile can delegate the sorting to sort(1)?  You 
wouldn't want Little Bobby Tables using this but who uses $(sort) on lists 
containing shell meta-characters like quotes?

martind@whitewater:~$ { echo 'strcoll = $(shell echo "$(1)" | fmt -w1 | sort)'; 
echo 'L:=$(call strcoll,B a)'; } | make -f - -p 2>&1 | grep '^L '
L := a B
martind@whitewater:~$


From: Rob Holbert [mailto:robholb...@gmail.com]
Sent: Sunday, July 17, 2011 10:13
To: Martin Dorey
Subject: Re: $(sort) - what is "lexical order"? (was RE: Follow-up)

I contend that the only useful purpose for the sort function is to alphabetize 
a list of items correctly. I realize that the out the box c strcmp function 
doesn't give us what we want exactly. The simple and obvious solution to sort 
the alphabet correctly in the ASCII world would be to put all strings in the 
same case prior to the comparison. Maybe $(alphabetize )? Just don't see 
any real use for the quasi-sort that presently exists. Why would you want to 
almost alphabetize a list of files or words? It's like a tease. lol.




On Tue, Jul 12, 2011 at 5:17 PM, Martin Dorey 
mailto:mdo...@bluearc.com>> wrote:
OP has something of a point: contrast the locale-dependent behavior of sort(1) 
with make's $(sort):

$ echo 'L:=$(sort B a)' | make -f - -p 2>&1 | grep '^L '
L := B a
$ { echo B; echo a; } | sort
a
B
$ { echo B; echo a; } | LC_ALL=C sort
B
a
$

I present this more to provoke "we can't change that!" and clarified 
documentation than as a serious suggestion:

Index: configure.in<http://configure.in>
===
RCS file: /sources/make/make/configure.in<http://configure.in>,v
retrieving revision 1.157
diff -u -r1.157 configure.in<http://configure.in>
--- configure.in<http://configure.in>29 Aug 2010 23:05:27 -   1.157
+++ configure.in<http://configure.in> 12 Jul 2011 21:11:28 -
@@ -166,6 +167,7 @@
 AC_CHECK_FUNCS(strcasecmp strncasecmp strcmpi strncmpi stricmp strnicmp)

 # strcoll() is used by the GNU glob library
+# and by $(sort)
 AC_FUNC_STRCOLL

 AC_FUNC_ALLOCA
Index: misc.c
===
RCS file: /sources/make/make/misc.c,v
retrieving revision 1.84
diff -u -r1.84 misc.c
--- misc.c  6 Nov 2010 21:56:24 -  1.84
+++ misc.c   12 Jul 2011 21:11:28 -
@@ -51,6 +51,10 @@
 # define VA_END(args)
 #endif

+#if !defined(HAVE_STRCOLL)
+# define strcoll strcmp
+#endif
+

 /* Compare strings *S1 and *S2.
Return negative if the first is less, positive if it is greater,
@@ -62,9 +66,7 @@
   const char *s1 = *((char **)v1);
   const char *s2 = *((char **)v2);

-  if (*s1 != *s2)
-return *s1 - *s2;
-  return strcmp (s1, s2);
+  return strcoll (s1, s2);
 }

 /* Discard each backslash-newline combination from LINE.
cvs diff: Diffing config
cvs diff: Diffing doc
Index: doc/make.texi
===
RCS file: /sources/make/make/doc/make.texi,v
retrieving revision 1.72
diff -u -r1.72 make.texi
--- doc/make.texi2 May 2011 15:11:23 - 1.72
+++ doc/make.texi 12 Jul 2011 21:11:28 -
@@ -6846,6 +6846,8 @@

 @noindent
 returns the value @samp{bar foo lose}.
+In a change from previous versions, make now sorts in locale-dependent order.
+Run with LC_ALL=C in the environment to select the previous behavior.

 @cindex removing duplicate words
 @cindex duplicate words, removing


From: 
bug-make-bounces+mdorey=bluearc.com<http://bluearc.com>@gnu.org<http://gnu.org> 
[mailto:bug-make-bounces+mdorey<mailto:bug-make-bounces%2Bmdorey>=bluearc.com<http://bluearc.com>@gnu.org<http://gnu.org>]
 On Behalf Of Rob Holbert
Sent: Monday, July 11, 2011 12:24
To: bug-make@gnu.org<mailto:bug-make@gnu.org>
Subject: Follow-up

Wanted to followup to my earlier email. Attached is the smallest makefile I 
could create to demonsterate the issue.

or

#does not sort lexically like expected
LIST = $(sort widget.c main.c ad.c Buzzer.c)
#target
all: list
list:
@echo $(LIST)
.PHONY: all list

Previous email:
Hello,

I ran across perhaps a bug or need for another feature at least. If a list of 
items has words beginning with both upper and lower case letters, the resulting 
$(sort $(LIST)) will result in all capital letter words coming before the lower 
case words. In this case, Zebra.c would appear befo

RE: $(sort) - what is "lexical order"? (was RE: Follow-up)

[Martin Dorey]

Putting OP's reply on the record.


From: Rob Holbert [mailto:robholb...@gmail.com]
Sent: Tuesday, July 19, 2011 04:49
To: Martin Dorey
Subject: Re: $(sort) - what is "lexical order"? (was RE: Follow-up)

Wow,

Just putting your sources in order yourself will be much better and make more 
sense I guess. Calling external sort is unwieldy and quite ridiculous (what was 
that about Mandarin?). The built-in sort has no use since it does not actually 
sort. I guess you answered my question, make is a very poor sorter, and chooses 
to remain that way. Another tool that does almost what you need, maybe we 
should brand it Microsoft since it is so inflexible.

At least describe in the manual that it "DOES NOT sort lexically". In fact, I 
am not quite sure what you would call it (useless?) I would definitely strive 
to make my sort function work like the native unix sort.  Do away with sort all 
together then since it doesn't work. Know you can't do it is much better than 
knowing you can almost do it.



On Mon, Jul 18, 2011 at 7:56 PM, Martin Dorey 
mailto:mdo...@bluearc.com>> wrote:
If I had check-in privs, I'd at least make this issue explicit in the 
documentation.  Even that, though, will require others on the list to be 
persuaded.

> Maybe $(alphabetize )?

Creative, but the name doesn't really work for writing systems, like Mandarin 
written in hanzi, without an alphabet.

Did you realize that your makefile can delegate the sorting to sort(1)?  You 
wouldn't want Little Bobby Tables using this but who uses $(sort) on lists 
containing shell meta-characters like quotes?

martind@whitewater:~$ { echo 'strcoll = $(shell echo "$(1)" | fmt -w1 | sort)'; 
echo 'L:=$(call strcoll,B a)'; } | make -f - -p 2>&1 | grep '^L '
L := a B
martind@whitewater:~$


From: Rob Holbert [mailto:robholb...@gmail.com<mailto:robholb...@gmail.com>]
Sent: Sunday, July 17, 2011 10:13
To: Martin Dorey
Subject: Re: $(sort) - what is "lexical order"? (was RE: Follow-up)

I contend that the only useful purpose for the sort function is to alphabetize 
a list of items correctly. I realize that the out the box c strcmp function 
doesn't give us what we want exactly. The simple and obvious solution to sort 
the alphabet correctly in the ASCII world would be to put all strings in the 
same case prior to the comparison. Maybe $(alphabetize )? Just don't see 
any real use for the quasi-sort that presently exists. Why would you want to 
almost alphabetize a list of files or words? It's like a tease. lol.




On Tue, Jul 12, 2011 at 5:17 PM, Martin Dorey 
mailto:mdo...@bluearc.com>> wrote:
OP has something of a point: contrast the locale-dependent behavior of sort(1) 
with make's $(sort):

$ echo 'L:=$(sort B a)' | make -f - -p 2>&1 | grep '^L '
L := B a
$ { echo B; echo a; } | sort
a
B
$ { echo B; echo a; } | LC_ALL=C sort
B
a
$

I present this more to provoke "we can't change that!" and clarified 
documentation than as a serious suggestion:

Index: configure.in<http://configure.in>
===
RCS file: /sources/make/make/configure.in<http://configure.in>,v
retrieving revision 1.157
diff -u -r1.157 configure.in<http://configure.in>
--- configure.in<http://configure.in>29 Aug 2010 23:05:27 -   1.157
+++ configure.in<http://configure.in> 12 Jul 2011 21:11:28 -
@@ -166,6 +167,7 @@
 AC_CHECK_FUNCS(strcasecmp strncasecmp strcmpi strncmpi stricmp strnicmp)

 # strcoll() is used by the GNU glob library
+# and by $(sort)
 AC_FUNC_STRCOLL

 AC_FUNC_ALLOCA
Index: misc.c
===
RCS file: /sources/make/make/misc.c,v
retrieving revision 1.84
diff -u -r1.84 misc.c
--- misc.c  6 Nov 2010 21:56:24 -  1.84
+++ misc.c   12 Jul 2011 21:11:28 -
@@ -51,6 +51,10 @@
 # define VA_END(args)
 #endif

+#if !defined(HAVE_STRCOLL)
+# define strcoll strcmp
+#endif
+

 /* Compare strings *S1 and *S2.
Return negative if the first is less, positive if it is greater,
@@ -62,9 +66,7 @@
   const char *s1 = *((char **)v1);
   const char *s2 = *((char **)v2);

-  if (*s1 != *s2)
-return *s1 - *s2;
-  return strcmp (s1, s2);
+  return strcoll (s1, s2);
 }

 /* Discard each backslash-newline combination from LINE.
cvs diff: Diffing config
cvs diff: Diffing doc
Index: doc/make.texi
===
RCS file: /sources/make/make/doc/make.texi,v
retrieving revision 1.72
diff -u -r1.72 make.texi
--- doc/make.texi2 May 2011 15:11:23 - 1.72
+++ doc/make.texi 12 Jul 2011 21:11:28 -
@@ -6846,6 +6846,8 @@

 @noindent
 returns the value @samp{bar foo lose}.

RE: $(sort) - what is "lexical order"? (was RE: Follow-up)

[Martin Dorey]

> Why not trivially s/lexical/ASCII/ on the affected line in the manual?

Because that could mislead someone who uses non-ASCII characters?  How about:

Index: doc/make.texi
===
RCS file: /sources/make/make/doc/make.texi,v
retrieving revision 1.72
diff -u -r1.72 make.texi
--- doc/make.texi   2 May 2011 15:11:23 -   1.72
+++ doc/make.texi   19 Jul 2011 19:20:36 -
@@ -6846,6 +6846,8 @@
 
 @noindent
 returns the value @samp{bar foo lose}.
+Results are returned in the "C" locale's collation order,
+regardless of LC_COLLATE's value.
 
 @cindex removing duplicate words
 @cindex duplicate words, removing

-Original Message-
From: David Boyce [mailto:david.s.bo...@gmail.com] 
Sent: Tuesday, July 19, 2011 12:09
To: psm...@gnu.org
Cc: Martin Dorey; robholb...@gmail.com; Bug-make@gnu.org
Subject: Re: $(sort) - what is "lexical order"? (was RE: Follow-up)

On Tue, Jul 19, 2011 at 3:00 PM, Paul Smith  wrote:

> I agree that the manual should document the fact that the sort function
> does not sort according the current LC_COLLATE value but instead always
> uses the standard ASCII (or LC_COLLATE="C") order.
>
> But I will not say that it doesn't sort lexically, because that's not
> true: it does.

Agree completely, and add a note to the OP that the sort function has
an extremely important side effect of removing repeated words. Another
reason to keep it, if that was meant seriously.

Why not trivially s/lexical/ASCII/ on the affected line in the manual?
Lexical may be technically correct but ASCII is more precise.

David Boyce

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #33958] Segfault in a 'define' with sort, foreach and newlines...

[Martin Dorey]

Follow-up Comment #1, bug #33958 (project make):

I think the whitespace was preserved in the email to me.  I could certainly
reproduce the problem using the snippet from the mail in 3.82.90.  But not in
CVS.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Evaluation of shell functions in recipes

[Martin Dorey]

> if we just read the docs wrong, or if they *are* wrong.



I don't think this is clearly explained in the docs.  Suggest:



Index: doc/make.texi

===

RCS file: /sources/make/make/doc/make.texi,v

retrieving revision 1.72

diff -u -r1.72 make.texi

--- doc/make.texi 2 May 2011 15:11:23 - 1.72

+++ doc/make.texi 15 Aug 2011 17:32:27 -

@@ -3620,6 +3620,7 @@

 References}).  This occurs after make has finished reading all the

 makefiles and the target is determined to be out of date; so, the

 recipes for targets which are not rebuilt are never expanded.

+The whole recipe is expanded before the first line is executed.



 Variable and function references in recipes have identical syntax and

 semantics to references elsewhere in the makefile.  They also have the



-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Stefan Tauner
Sent: Sunday, August 14, 2011 12:43
To: bug-make@gnu.org
Cc: Stefan Tauner; Carl-Daniel Hailfinger
Subject: Evaluation of shell functions in recipes



hello!



please keep our CC:s because we are not subscribed.

i have found a bug in our (flashrom.org) makefile which may be a bug in

make or its documentation.

attached is a small test case makefile.



the related documentation is

http://www.gnu.org/s/hello/manual/make/Shell-Function.html

and

http://www.gnu.org/s/hello/manual/make/Reading-Makefiles.html



the problem is that the shell function runs before any other commands

(i.e. immediate).

the documentation of the shell function states:

"The commands run by calls to the shell function are run when the

function calls are expanded."

and from the "reading makefiles" section i would say that this should

be deferred i.e. the commands of the recipe should be evaluated

sequently. instead the shell functions are run first:

- 2 is written to the test file

- 4 is written to the test file (overwriting 2)

after that the normal execution starts.

this leads to the output (among other things) of "1 4 4 3 4".

the expected output is "1  2 3 4"



could someone please explain if the observed behavior is "right" and if

we just read the docs wrong, or if they *are* wrong.

thanks!

--

Kind regards/Mit freundlichen Grüßen, Stefan Tauner
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: bug report : ERROR: dev-libs/lzo-2.06 failed (compile phase)

[Martin Dorey]

That's not a bug in make.  It's a bug in whatever called make.  You'd have to 
take that up with whoever maintains, what, lzo?  They seem to have done:

martind@whitewater:~$ make -j7-l7
make: the `-j' option requires a positive integral argument
Usage: make [options] [target] ...

When they probably meant to have a space between the switches, comme ça:

martind@whitewater:~$ make -j7 -l7
make: *** No targets specified and no makefile found.  Stop.
martind@whitewater:~$

-Original Message-
From: bug-make-bounces+martin.dorey=hds@gnu.org 
[mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Christophe 
Poncy
Sent: Wednesday, April 25, 2012 17:19
To: bug-make@gnu.org
Subject: bug report : ERROR: dev-libs/lzo-2.06 failed (compile phase)

Hi,
I have a have a bug during the compile phase of my Funtoo GNU/Linux
box. I was trying to emerge the 'boot-update' package, it seems there is
a problem for compiling one of its dependency (lzo ).

Here is the complete build log :


# cat /var/tmp/portage/dev-libs/lzo-2.06/temp/build.log
  * Package:dev-libs/lzo-2.06
  * Repository: gentoo
  * Maintainer: bi...@gentoo.org
  * USE:amd64 elibc_glibc kernel_linux multilib userland_GNU
  * FEATURES:   preserve-libs sandbox
>>> Unpacking source...
>>> Unpacking lzo-2.06.tar.gz to
>>> /var/tmp/portage/dev-libs/lzo-2.06/work
>>> Source unpacked in /var/tmp/portage/dev-libs/lzo-2.06/work
>>> Preparing source in
>>> /var/tmp/portage/dev-libs/lzo-2.06/work/lzo-2.06 ...
  * QA Notice: The 'hasq' function is deprecated (replaced by 'has')
>>> Source prepared.
>>> Configuring source in
>>> /var/tmp/portage/dev-libs/lzo-2.06/work/lzo-2.06 ...
  * econf: updating lzo-2.06/autoconf/config.guess with
/usr/share/gnuconfig/config.guess
  * econf: updating lzo-2.06/autoconf/config.sub with
/usr/share/gnuconfig/config.sub
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --libdir=/usr/lib64
--disable-dependency-tracking --docdir=/usr/share/doc/lzo-2.06
--enable-shared --disable-static
configure: Configuring LZO 2.06
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking whether to enable maintainer-specific portions of Makefiles...
no
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none
needed
checking whether x86_64-pc-linux-gnu-gcc and cc understand -c and -o
together... yes
checking for style of include used by make... GNU
checking dependency style of x86_64-pc-linux-gnu-gcc... none
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
checking whether the C preprocessor needs special flags... none needed
checking for an ANSI C-conforming const... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking dependency style of x86_64-pc-linux-gnu-gcc... none
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by x86_64-pc-linux-gnu-gcc...
/usr/x86_64-pc-linux-gnu/bin/ld
checking if the linker (/usr/x86_64-pc-linux-gnu/bin/ld) is GNU ld...
yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/x86_64-pc-linux-gnu/bin/ld option to reload object
files... -r
checking for x86_64-pc-linux-gnu-objdump... x86_64-pc-linux-gnu-objdump
checking how to recognize depe

RE: [bug #33138] .PARLLELSYNC enhancement with patch

[Martin Dorey]

> They surely store the uncompressed size somewhere

NTFS certainly stores that.  It's the field referred to as "real" at eg 
http://ftp.kolibrios.org/users/Asper/docs/NTFS/ntfsdoc.html#id4793056.  
("allocated" is what it says on the tin.  "initialized" would be smaller than 
"real" if it's compressed or sparse.)

> but I'd be surprised if any fs actually worked this way

Perhaps something that wrote to tape, long enough ago that it's missing all the 
layers of abstraction that Frank rightly mentions.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: [bug #39028] [patch] fix and uniformize four error messages

[Martin Dorey]

> I think "integer" is meant instead of "integral".

Eg C99 uses "integral" as an adjective meaning "of integers", per 1 b (1) from 
http://www.merriam-webster.com/dictionary/integral.  My googling suggests that 
the OP's right, though, that the patched would be more widely understood.

-Original Message-
From: bug-make-bounces+martin.dorey=hds@gnu.org 
[mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Benno 
Schulenberg
Sent: Monday, May 20, 2013 12:27
To: Benno Schulenberg; psm...@gnu.org; bo...@kolpackov.net; bug-make@gnu.org
Subject: [bug #39028] [patch] fix and uniformize four error messages

URL:
  

 Summary: [patch] fix and uniformize four error messages
 Project: make
Submitted by: bens
Submitted on: Mon 20 May 2013 09:27:25 PM CEST
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

One error message says "option requires a positive integral argument", where I
think "integer" is meant instead of "integral".

Attached patch fixes that, decapitalizes another message, removes an
inconsistent period from a third one, and adds two clarifying words to a
fourth.



___

File Attachments:


---
Date: Mon 20 May 2013 09:27:26 PM CEST  Name:
0001-Fix-wording-of-two-error-messages-and-uniformize-two.patch  Size: 2kB  
By: bens



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

[Martin Dorey]

Frank wrote:

> the two-step procedure (remove and ">>").

Woah, *truncate* and ">>".  Removal wouldn't do the right thing for symlinks.

> That said, I'm now going back to my own programs which redirect
> stdout in forked child processes and add O_APPEND to O_TRUNC ...

Me too!


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Help:Stop compile due to Segmentation Fault Error

[Martin Dorey]

(Bcc: help-m...@gnu.org - this is definitely a make 
bug)


Ø  part of Makefile

So not enough for us to try to repeat it.  It looked vaguely familiar and 
Google turned up something similar, sadly with no obvious resolution:

http://lists.gnu.org/archive/html/bug-make/2007-10/msg00049.html


Ø  Can you guide us with what we should do?

Does it happen every time?  Have you tried with make-3.82, with the release 
candidate for the upcoming release 
http://lists.gnu.org/archive/html/make-alpha/2013-05/msg00023.html, with make 
from git http://savannah.gnu.org/git/?group=make?

From: bug-make-bounces+martin.dorey=hds@gnu.org 
[mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of ???
Sent: Friday, June 21, 2013 07:09
To: bug-make@gnu.org; help-m...@gnu.org
Subject: Help:Stop compile due to Segmentation Fault Error

Dear GNU.org

I have a problem with make file.
Segmentation Fault error occurred while compile below part of Makefile.
we used the make 3.81 on ubentu 10.10.

$(APKCERTS_FILE):
   @echo APK certs list: $@
   @mkdir -p $(dir $@)
   @rm -f $@
   $(eval APKCERTS_TMP_FILE := $(shell mktemp))
   $(hide) $(foreach p,$(PACKAGES),\
  $(if $(PACKAGES.$(p).EXTERNAL_KEY),\
   echo 'name="$(p).apk" certificate="EXTERNAL" \
private_key=""' >> $(APKCERTS_TMP_FILE);,\
   echo 'name="$(p).apk" certificate="$(PACKAGES.$(p).CERTIFICATE)" 
\
private_key="$(PACKAGES.$(p).PRIVATE_KEY)"' >> 
$(APKCERTS_TMP_FILE);))
   @mv $(APKCERTS_TMP_FILE) $@
   $(hide) touch $@


Here is the call stack of Segmentation Fault error

#0  eval_buffer (buffer=0xddd9390 "APKCERTS_TMP_FILE := /tmp/tmp.WBLP9iHl4m") 
at read.c:430
#1  0x00407b5a in func_eval (o=0x13f748a1 "\002\324=\356\177", 
argv=0x7fffdc35d700, funcname=) at function.c:1369
#2  0x0040a81c in handle_function (op=0x7fffdc35d830, stringp=) at function.c:2213
#3  0x004058d3 in variable_expand_string (line=0x13f748a0 
"\t\002\324=\356\177", string=0x13f7fd80 "\t$(eval APKCERTS_TMP_FILE := $(shell 
mktemp))", length=-1)
at expand.c:253
#4  0x00405da3 in variable_expand_for_file (line=, 
file=) at expand.c:463
#5  0x0040541b in allocated_variable_expand_for_file (line=, file=) at expand.c:548
#6  0x0040e277 in new_job (file=0x1b135270) at job.c:1600
#7  0x00418b76 in remake_file (file=0x1b135270, depth=8) at 
remake.c:1123
#8  update_file_1 (file=0x1b135270, depth=8) at remake.c:761
#9  update_file (file=0x1b135270, depth=8) at remake.c:307
#10 0x004190f3 in check_dep (file=0x1b135270, depth=8, this_mtime=1, 
must_make_ptr=0x7fffdc35da94) at remake.c:947
#11 0x00418097 in update_file_1 (file=0x1b3be190, depth=6) at 
remake.c:508

Can you guide us with what we should do?

Thank You
ERIC
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Help:Stop compile due to Segmentation Fault Error

[Martin Dorey]

> the problem is that Ubuntu (and Debian) ship a very outdated release of
> GNU make

The current, recent Debian stable, "Wheezy", ships with a version of make that 
it pleases Debian to call 3.81-8.2, per http://packages.debian.org/wheezy/make. 
 Per the changelog link to 
http://ftp-master.metadata.debian.org/changelogs//main/m/make-dfsg/make-dfsg_3.81-8.2_changelog,
 that includes the fix for 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622644 which is the bug cited 
here, http://savannah.gnu.org/bugs/?20033.

-Original Message-
From: bug-make-bounces+martin.dorey=hds@gnu.org 
[mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Michael 
Stahl
Sent: Saturday, June 22, 2013 10:03
To: bug-make@gnu.org
Cc: help-m...@gnu.org
Subject: Re: Help:Stop compile due to Segmentation Fault Error

On 21/06/13 16:09, 최철우 wrote:
> Dear GNU.org
> 
> I have a problem with make file. 
> 
> Segmentation Fault error occurred while compile below part of Makefile.
> 
> we used the make 3.81 on ubentu 10.10. 

ok...

>$(eval APKCERTS_TMP_FILE := $(shell mktemp))

using eval...

> Here is the call stack of Segmentation Fault error
> 
> #0  eval_buffer (buffer=0xddd9390 "APKCERTS_TMP_FILE := /tmp/tmp.WBLP9iHl4m") 
> at read.c:430
> 
> #1  0x00407b5a in func_eval (o=0x13f748a1 "\002\324=\356\177", 
> argv=0x7fffdc35d700, funcname=) at function.c:1369

i bet you're running into this bug:

http://savannah.gnu.org/bugs/?20033

... which happens to be very familiar to me :)

> Can you guide us with what we should do?

the problem is that Ubuntu (and Debian) ship a very outdated release of
GNU make; as you can see the bug was fixed in 2007 already.

you can either:

- upgrade to GNU make 3.82 or newer

- apply the patch referenced in the bug report to GNU make 3.81 and
rebuild (this has reliably solved the problem for me)

- stop using -jN and build without parallelism (and much slower)



___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #39709] a few typos fixes

[Martin Dorey]

Follow-up Comment #1, bug #39709 (project make):

The patch looks good to me and I'm a picky native speaker.  My one not-really
quibble was why not also fix the "pattrn" targets in
tests/scripts/features/patspecific_vars.  I'm not seeing the reason why
"pattern" has to be avoided, but it's unfamiliar source operating in an
unfamiliar environment.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40159] Premature exit with incorrect error message, or garbage output characters.

[Martin Dorey]

Follow-up Comment #5, bug #40159 (project make):

On a version (3.99.92) from Git the other day, the example's output ends
with:

Makefile:12:   i 
Makefile:12:   i 
make: Nothing to be done for 'dummy'.

It exits with status zero.  valgrind doesn't notice anything scary.

With the make ("3.81-8") from Debian Squeeze, I get the same output and exit
status *but* valgrind throws off 23 invalid reads.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40159] Premature exit with incorrect error message, or garbage output characters.

[Martin Dorey]

Follow-up Comment #6, bug #40159 (project make):

Debian's make 3.81-8.2, from Wheezy and Sid, behaves like Squeeze, as does
make-3.82 built on Debian via Paul's instructions here.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #40159] Premature exit with incorrect error message, or garbage output characters.

[Martin Dorey]

Follow-up Comment #9, bug #40159 (project make):

I repeated all my tests with both makefiles.  In all tests, they behaved like
the original.  So this is a bug that's been fixed here since 3.82.  Debian has
taken many patches from here but hasn't taken whichever one fixed this.  Can
we say which it is?  Here's one of the valgrind plaints:

==23456== Invalid read of size 1
==23456==at 0x4C25FF8: memcpy (mc_replace_strmem.c:497)
==23456==by 0x4058A1: variable_buffer_output (expand.c:72)
==23456==by 0x405A15: variable_expand_string (expand.c:234)
==23456==by 0x40610A: allocated_variable_expand_for_file (expand.c:574)
==23456==by 0x4061EF: recursively_expand_for_file (expand.c:142)
==23456==by 0x405EC8: variable_expand_string (expand.c:176)
==23456==by 0x40610A: allocated_variable_expand_for_file (expand.c:574)
==23456==by 0x4063AA: expand_argument (expand.c:458)
==23456==by 0x40A8F2: handle_function (function.c:2241)
==23456==by 0x405AAA: variable_expand_string (expand.c:263)
==23456==by 0x40610A: allocated_variable_expand_for_file (expand.c:574)
==23456==by 0x4061EF: recursively_expand_for_file (expand.c:142)
==23456==  Address 0x55dede0 is 16 bytes inside a block of size 17 free'd
==23456==at 0x4C240FD: free (vg_replace_malloc.c:366)
==23456==by 0x41CE84: define_variable_in_set (variable.c:228)
==23456==by 0x41D26F: do_variable_definition (variable.c:1334)
==23456==by 0x41D4AA: try_variable_definition (variable.c:1521)
==23456==by 0x416085: eval (read.c:722)
==23456==by 0x417407: eval_buffer (read.c:459)
==23456==by 0x4081D9: func_eval (function.c:1374)
==23456==by 0x40A92D: handle_function (function.c:2273)
==23456==by 0x405AAA: variable_expand_string (expand.c:263)
==23456==by 0x40610A: allocated_variable_expand_for_file (expand.c:574)
==23456==by 0x4061EF: recursively_expand_for_file (expand.c:142)
==23456==by 0x405EC8: variable_expand_string (expand.c:176)

It's https://savannah.gnu.org/patch/?7534. 
https://savannah.gnu.org/patch/download.php?file_id=23309 applies cleanly to
Debian Squeeze's make source and makes the problem go away.  Well, it makes my
valgrind symptom go away.  I bet the cause is the same for the OP's problem. 
OP should try something like this:

apt-get source make
cd make-dfsg-3.81
dpkg-buildpackage -nc
./make -f .../premature-Makefile -R -r
# check you still have the problem

wget -O - https://savannah.gnu.org/patch/download.php?file_id=23309 | patch
-p1
make
./make -f .../premature-Makefile -R -r
# check you don't

If it fixes your symptom too, then I recommend you raise a Debian bug citing
this one.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

[Martin Dorey]

Follow-up Comment #19, bug #33034 (project make):

The attached version of boyski's patch with, as Paul suggests, just the change
from fatal to error and the addition of "warning: ", fixes the kernel eg
2.6.32-5 driver build problem I otherwise have with eg make-3.82, make-4.0. 
(I've been using a copy of Debian's older version, with its memory corruption
bugs, for my kernel driver builds.)

(file #29365)
___

Additional Item Attachment:

File name: smaller-allow.patchSize:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Excessive $(strip)

[Martin Dorey]

> this also removes the newlines.
...
> IMHO make 4.x has a too strict definition of white-space.

http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html sayeth:

"In the POSIX locale, at a minimum, the , , , 
, , and  shall be included."

Case closed?

-Original Message-
From: bug-make-bounces+martin.dorey=hds@gnu.org 
[mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Gisle Vanem
Sent: Wednesday, April 02, 2014 05:11
To: bug-make@gnu.org
Subject: Excessive $(strip)

I'm a happy user of the $(file) function and multiline macros/variables
likes this:
..
define FOO_PACKAGE
  exec_prefix=$(FOO_ROOT)
  libdir=$${exec_prefix}/lib
  includedir=$${exec_prefix}/inc
  Version: $(FOO_VERSION)
  Libs: $${libdir}/$(FOO_LIB)
endef

write_pkg:
  $(file > ./foo.pc, $(strip $(FOO_PACKAGE)))

Since I suspect some older pkgconfig programs doesn't like the leading
spaces in foo.pc, I'm using $(strip). But this also removes the newlines. 

My make-manual documents that "white space" gets stripped off. IMHO 
make 4.x has a too strict definition of white-space. Or have I misunderstood 
how $(strip) is supposed to work?

But I could always have 'define FOO_PACKAGE'
without the leading spaces and do:

write_pkg:
 $(file > ./foo.pc,$(FOO_PACKAGE))

But I prefer the nice indent.

--gv

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Excessive $(strip)

[Martin Dorey]

> Then the make manual is a bit sloppy in the use of "whitespace".
> E.g. from the man-page (3.3 Including Other Makefiles):
>  "Whitespace is required between include and the file names, and between file 
> names"

That sounded all too plausible, so I went through all the mentions of 
/whitespace/i in make.texi with the intent to produce a patch.  I think you've 
got a good case with the quoted part of 3.3:

martind@whitewater:~/playpen$ cat variable-include.make 
define VERTICAL_SPACE




endef

include $(VERTICAL_SPACE) filename.make
martind@whitewater:~/playpen$ make -f variable-include.make 
variable-include.make:8: 


: No such file or directory
make: *** No rule to make target '


'.  Stop.
martind@whitewater:~/playpen$

> (plus section 5.9 etc. etc.)

I think Gisle refers to:

>> It is sometimes useful to define recipes which do nothing.  This is done
>> simply by giving a recipe that consists of nothing but whitespace.  For
>> example:
>>
>> target: ;

I tried a similar test case and that, unlike the 3.3 one, seemed to work:

martind@whitewater:~/playpen$ cat 
vertical-whitespace-in-otherwise-empty-recipe.make 
define VERTICAL_SPACE




endef

mytarget: $(VERTICAL_SPACE);
martind@whitewater:~/playpen$ make -f 
vertical-whitespace-in-otherwise-empty-recipe.make  
make: 'mytarget' is up to date.
martind@whitewater:~/playpen$

The file command seems less tolerant:

martind@whitewater:~/playpen$ cat vertical-whitespace-in-file-command.make
define VERTICAL_SPACE




endef

$(file > $(VERTICAL_SPACE) file.txt,text)
martind@whitewater:~/playpen$ rm -f file.txt; make -f 
vertical-whitespace-in-file-command.make; cat file.txt
make: *** No targets.  Stop.
cat: file.txt: No such file or directory
martind@whitewater:~/playpen$ echo *file.txt



 file.txt
martind@whitewater:~/playpen$ rm *file.txt
martind@whitewater:~/playpen$

Heh.  So my suggestion would be:

martind@whitewater:~/download/make-git/make/doc$ git diff
diff --git a/doc/make.texi b/doc/make.texi
index 8fbdb61..c7122ef 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -1173,9 +1173,9 @@ include @var{filenames}@dots{}
 Extra spaces are allowed and ignored at the beginning of the line, but
 the first character must not be a tab (or the value of
 @code{.RECIPEPREFIX})---if the line begins with a tab, it will be
-considered a recipe line.  Whitespace is required between
+considered a recipe line.  Horizontal whitespace is required between
 @code{include} and the file names, and between file names; extra
-whitespace is ignored there and at the end of the directive.  A
+horizontal whitespace is ignored there and at the end of the directive.  A
 comment starting with @samp{#} is allowed at the end of the line.  If
 the file names contain any variable or function references, they are
 expanded.  @xref{Using Variables, ,How to Use Variables}.
@@ -7522,7 +7522,7 @@ $(file @var{op} @var{filename},@var{text})
 The operator @var{op} can be either @code{>} which indicates overwrite
 mode, or @code{>>} which indicates append mode.  The @var{filename}
 indicates the file to be written to.  There may optionally be
-whitespace between the operator and the file name.
+horizontal whitespace between the operator and the file name.
 
 When the @code{file} function is expanded all its arguments are
 expanded first, then the file indicated by @var{filename} will be
martind@whitewater:~/download/make-git/make/doc$

I think that I've (somewhat deliberately) missed the real point, about the 
syntax of makefiles, rather than the semantics.  Perhaps that's the purview of 
3.1 What Makefiles Contain and 3.1.1 Splitting Long Lines.  Perhaps that could 
afford to be explicit that directives, except for define, are terminated by an 
unescaped newline.

-Original Message-
From: bug-make-bounces+martin.dorey=hds@gnu.org 
[mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Gisle Vanem
Sent: Thursday, April 03, 2014 07:37
To: bug-make@gnu.org
Subject: Re: Excessive $(strip)

"Martin Dorey"  wrote:

>> this also removes the newlines.
>...
>> IMHO make 4.x has a too strict definition of white-space.
>
> http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html 
> sayeth:
>
> "In the POSIX locale, at a minimum, the , , , 
> , , and  shall be included."

Then the make manual is a bit sloppy in the use of "whitespace".
E.g. from the man-page (3.3 Including Other Makefiles):
 "Whitespace is required between include and the file names, and between file 
names"

(plus section 5.9 etc. etc.)

So a:
  include 
  foo.mak

---

should work if that definition was true everywhere, but it doesn't. 

--gv

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Excessive $(strip)

[Martin Dorey]

> I'd say that make itself is sloppy wrt whitespace, where sometimes
> newlines are considered to be whitespace, othertimes not.
...
> the "word" family of functions do not.

Nice example.  The source seems to draw a distinction between isblank, 
terminology available, I learn, in C99, and the more familiar isspace.  The 
word "blanks" is used in the documentation, but not as frequently as the source 
suggests and not, afaics, in relation to the "words" function.  I retract my 
previous suggested patch in favor of this.  It doesn't go nearly far enough, 
but verifying each mention of whitespace now looks like more than I'd bargained 
for.

martind@whitewater:~/download/make-git/make$ git diff
diff --git a/doc/make.texi b/doc/make.texi
index 8fbdb61..2932c03 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -1173,9 +1173,9 @@ include @var{filenames}@dots{}
 Extra spaces are allowed and ignored at the beginning of the line, but
 the first character must not be a tab (or the value of
 @code{.RECIPEPREFIX})---if the line begins with a tab, it will be
-considered a recipe line.  Whitespace is required between
+considered a recipe line.  At least one blank is required between
 @code{include} and the file names, and between file names; extra
-whitespace is ignored there and at the end of the directive.  A
+blanks are ignored there and at the end of the directive.  A
 comment starting with @samp{#} is allowed at the end of the line.  If
 the file names contain any variable or function references, they are
 expanded.  @xref{Using Variables, ,How to Use Variables}.
@@ -7522,7 +7522,7 @@ $(file @var{op} @var{filename},@var{text})
 The operator @var{op} can be either @code{>} which indicates overwrite
 mode, or @code{>>} which indicates append mode.  The @var{filename}
 indicates the file to be written to.  There may optionally be
-whitespace between the operator and the file name.
+blanks between the operator and the file name.
 
 When the @code{file} function is expanded all its arguments are
 expanded first, then the file indicated by @var{filename} will be
martind@whitewater:~/download/make-git/make$

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make 4.0 crashes on Solaris 8

[Martin Dorey]

The vsnprintf thing was (probably) fixed in git under 
http://savannah.gnu.org/bugs/?40361.

From: Tom Kacvinsky [mailto:tom.kacvin...@vectorcast.com]
Sent: Thursday, April 17, 2014 07:23 AM
To: Bug-make@gnu.org 
Subject: GNU make 4.0 crashes on Solaris 8

I have successfully built GNU make 4.0 on a Solaris 8 machine, using GCC 4.7.3 
and Sun Studio 11, but when I run "make check", make dumps core

Core was generated by `/Datastore/Public/tjk/make/src/make-4.0/tests/../make -f 
work/features/se_expli'.
Program terminated with signal 11, Segmentation fault.
#0  0xff108ac8 in vsnprintf () from /lib/libc.so.1
(gdb) where
#0  0xff108ac8 in vsnprintf () from /lib/libc.so.1
#1  0x0003dbd8 in vfmtconcat (fmt=0x5d26c "prerequisites cannot be defined in 
recipes", args=0xffbfe8dc) at output.c:631
#2  0x0003e038 in fatal (flocp=0xffbfe9e8, fmt=0x5d26c "prerequisites cannot be 
defined in recipes", ...=0x2e68) at output.c:737
#3  0x00042c30 in record_files (filenames=0x854d0, pattern=0x0, 
pattern_percent=0x0, depstr=0x854e0 "proj1.c", cmds_started=1, commands=0x86840 
"", commands_idx=0, two_colon=0,
prefix=9 '\t', flocp=0xffbfe9e8) at read.c:1951
#4  0x00040160 in eval (ebuf=0xffbfeab4, set_default=1) at read.c:1008
#5  0x0003ece4 in eval_buffer (buffer=0x866a0 "proj1.o : proj1.c", floc=0x0) at 
read.c:482
#6  0x00029bd8 in func_eval (o=0x7f140 "e :  proj1.o $(eval $(test))", 
argv=0xffbfec08, funcname=0x5aec4 "eval") at function.c:1352
#7  0x0002af3c in expand_builtin_function (o=0x7f140 "e :  proj1.o $(eval 
$(test))", argc=1, argv=0xffbfec08, entry_p=0x6f0b4 
<$XA6sV5Q1G_TT35K.function_table_init+408>)
at function.c:2294
#8  0x0002b41c in handle_function (op=0xffbfecf0, stringp=0xffbfecf8) at 
function.c:2415
#9  0x00021754 in variable_expand_string (line=0x7f138 "proj1.o e :  proj1.o 
$(eval $(test))", string=0x833f8 "proj1.o $(eval $(test))", length=-1) at 
expand.c:256
#10 0x00021dcc in variable_expand (line=0x833f8 "proj1.o $(eval $(test))") at 
expand.c:419
#11 0x00022020 in variable_expand_for_file (line=0x833f8 "proj1.o $(eval 
$(test))", file=0x886a0) at expand.c:478
#12 0x00023c88 in expand_deps (f=0x886a0) at file.c:605
#13 0x00023f34 in snap_deps () at file.c:688
#14 0x00037a04 in main (argc=3, argv=0xffbffc0c, envp=0xffbffc1c) at main.c:2076

Any ideas as to what is going on?  I would like to see if an issue I 
encountered in 3.82 (related to a file compiling twice when running make in 
parallel) is fixed in this version.

Thanks,

Tom
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Make does not throw an error for target without a recipe?

[Martin Dorey]

> Why is it trying to build target test.mk...???

That's explained by 
https://www.gnu.org/software/make/manual/make.html#Remaking-Makefiles.

> Then it decides it was successful?

For some value of "successful".  With your makefile:

martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo
make: Nothing to be done for `foo'.
martind@swiftboat:~/tmp/batrick-2014-06-26$

If we add a semicolon, telling make that the recipe to update foo is empty:

martind@swiftboat:~/tmp/batrick-2014-06-26$ sed -i -e 's/passwd/passwd;/' 
test.mk
martind@swiftboat:~/tmp/batrick-2014-06-26$ 

Then the message changes:

martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo
make: `foo' is up to date.
martind@swiftboat:~/tmp/batrick-2014-06-26$

If we give it a recipe that actually works:

martind@swiftboat:~/tmp/batrick-2014-06-26$ sed -i -e 's/passwd;/passwd; @touch 
$@/' test.mk
martind@swiftboat:~/tmp/batrick-2014-06-26$

Then we get silent success, following the Unix Bushido:

martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo
martind@swiftboat:~/tmp/batrick-2014-06-26$

Though a second invocation has nothing to do, and says so:

martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo
make: `foo' is up to date.
martind@swiftboat:~/tmp/batrick-2014-06-26$

-Original Message-
From: bug-make-bounces+martin.dorey=hds@gnu.org 
[mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Patrick 
Donnelly
Sent: Thursday, June 26, 2014 13:20
To: bug-make@gnu.org
Subject: Make does not throw an error for target without a recipe?

See example:


---8<---
TARGETS = foo

all: $(TARGETS)

$(TARGETS): /etc/passwd
--->8---

This is the debug output I get from running this test.mk, comments inline:

$ make -f test.mk -d foo
GNU Make 4.0
Built for x86_64-unknown-linux-gnu
Copyright (C) 1988-2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'test.mk'...
Updating makefiles
 Considering target file 'test.mk'.
  Looking for an implicit rule for 'test.mk'.
[...]

Why is it trying to build target test.mk...???


 File 'foo' does not exist.
 Looking for an implicit rule for 'foo'.
[...]
 No implicit rule found for 'foo'.
  Considering target file '/etc/passwd'.
   Looking for an implicit rule for '/etc/passwd'.
[...]
   No implicit rule found for '/etc/passwd'.
   Finished prerequisites of target file '/etc/passwd'.
  No need to remake target '/etc/passwd'.
 Finished prerequisites of target file 'foo'.
Must remake target 'foo'.
Successfully remade target file 'foo'.
make: Nothing to be done for 'foo'.

So the interesting thing here is that Make decides it needs to remake
`foo' but it doesn't do anything (based on strace output). Then it
decides it was successful? That doesn't make any sense... How do I get
Make to fail if it can't make the target? In case it matters, I'm
bringing this problem up because targets are not being created (as
expected) by implicit rules but I don't know this because make claims
success.

Thanks for any help,

-- 
Patrick Donnelly

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Make does not throw an error for target without a recipe?

[Martin Dorey]

> I'm afraid none of this exercise is helpful for solving the problem

Perhaps putting my point in different words will better convey it: you could 
simply adjust your expectation, to regard this as a failure:

make: Nothing to be done for `foo'.

But...

> To put it concisely: how do I get Make to *fail* if it cannot
> create one of the targets?

... if you're really insistent on "get Make to return a non-zero exit status if 
I haven't told it how to create one of the targets" then, per 
http://www.gnu.org/software/make/manual/make.html#Last-Resort, you could do:

martind@swiftboat:~/tmp/batrick-2014-06-26$ cat test.mk
TARGETS = foo

all: $(TARGETS)

$(TARGETS): /etc/passwd

%::; @echo no recipe for $@ 1>&2 && exit 1
martind@swiftboat:~/tmp/batrick-2014-06-26$ rm foo
martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo; echo $?
no recipe for foo
make: *** [foo] Error 1
2
martind@swiftboat:~/tmp/batrick-2014-06-26$

If Make doesn't think foo needs an update, mind:

martind@swiftboat:~/tmp/batrick-2014-06-26$ touch foo
martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo; echo $?
make: `foo' is up to date.
0
martind@swiftboat:~/tmp/batrick-2014-06-26$

-Original Message-
From: Patrick Donnelly [mailto:batr...@batbytes.com] 
Sent: Thursday, June 26, 2014 13:43
To: Martin Dorey
Cc: bug-make@gnu.org
Subject: Re: Make does not throw an error for target without a recipe?

Hi Martin,

On Thu, Jun 26, 2014 at 4:33 PM, Martin Dorey  wrote:
>> Why is it trying to build target test.mk...???
>
> That's explained by 
> https://www.gnu.org/software/make/manual/make.html#Remaking-Makefiles.

Thanks, that makes sense.

>> Then it decides it was successful?
>
> For some value of "successful".  With your makefile:
>
> martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo
> make: Nothing to be done for `foo'.
> martind@swiftboat:~/tmp/batrick-2014-06-26$
>
> If we add a semicolon, telling make that the recipe to update foo is empty:
>
> martind@swiftboat:~/tmp/batrick-2014-06-26$ sed -i -e 's/passwd/passwd;/' 
> test.mk
> martind@swiftboat:~/tmp/batrick-2014-06-26$
>
> Then the message changes:
>
> martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo
> make: `foo' is up to date.
> martind@swiftboat:~/tmp/batrick-2014-06-26$
>
> If we give it a recipe that actually works:
>
> martind@swiftboat:~/tmp/batrick-2014-06-26$ sed -i -e 's/passwd;/passwd; 
> @touch $@/' test.mk
> martind@swiftboat:~/tmp/batrick-2014-06-26$
>
> Then we get silent success, following the Unix Bushido:
>
> martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo
> martind@swiftboat:~/tmp/batrick-2014-06-26$
>
> Though a second invocation has nothing to do, and says so:
>
> martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo
> make: `foo' is up to date.
> martind@swiftboat:~/tmp/batrick-2014-06-26$

I'm afraid none of this exercise is helpful for solving the problem
though. To put it concisely: how do I get Make to *fail* if it cannot
create one of the targets?

-- 
Patrick Donnelly
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Make does not throw an error for target without a recipe?

[Martin Dorey]

Maybe that's why my code always uses 
https://www.gnu.org/software/make/manual/make.html#Static-Pattern:

martind@swiftboat:~/tmp/batrick-2014-06-26$ cat test.mk
.SUFFIXES:

TARGETS = foo

$(addsuffix .o,$(TARGETS)): %.o: %.c; cc -o $@ $<

$(TARGETS): %: %.o; ld -o $@ $^

%::; @echo no recipe for $@ 1>&2 && exit 1
martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo
no recipe for foo.c
make: *** [foo.c] Error 1
martind@swiftboat:~/tmp/batrick-2014-06-26$ echo 'int main() {}' > foo.c
martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo
cc -o foo.o foo.c
ld -o foo foo.o
ld: error in foo.o(.eh_frame); no .eh_frame_hdr table will be created.
martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo
make: `foo' is up to date.
martind@swiftboat:~/tmp/batrick-2014-06-26$

-Original Message-
From: Patrick Donnelly [mailto:batr...@batbytes.com] 
Sent: Thursday, June 26, 2014 14:06
To: Martin Dorey
Cc: bug-make@gnu.org
Subject: Re: Make does not throw an error for target without a recipe?

On Thu, Jun 26, 2014 at 5:02 PM, Martin Dorey  wrote:
>> I'm afraid none of this exercise is helpful for solving the problem
>
> Perhaps putting my point in different words will better convey it: you could 
> simply adjust your expectation, to regard this as a failure:
>
> make: Nothing to be done for `foo'.
>
> But...
>
>> To put it concisely: how do I get Make to *fail* if it cannot
>> create one of the targets?
>
> ... if you're really insistent on "get Make to return a non-zero exit status 
> if I haven't told it how to create one of the targets" then, per 
> http://www.gnu.org/software/make/manual/make.html#Last-Resort, you could do:
>
> martind@swiftboat:~/tmp/batrick-2014-06-26$ cat test.mk
> TARGETS = foo
>
> all: $(TARGETS)
>
> $(TARGETS): /etc/passwd
>
> %::; @echo no recipe for $@ 1>&2 && exit 1

Is there a way to get last-resort rules to play nicely with e.g.:

%.o: %.c
cc -o $@ $<
%: %.o
ld -o $@ $^ ...

The last-resort rule is preferred over the the %.c -> %.o -> % chain of rules.

-- 
Patrick Donnelly
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Buffer overflow in orig/implicit.c

[Martin Dorey]

3.82 isn't the latest.  It looks like someone beat you to it:

Differences between revisions 3f6bb04e75e5a02f23339c9d4bec99b22d430803 and 
6405534814f04899890a2d932db9a4985fd772fe:

2012-02-26 21:34:51 + psm...@gnu.org 
(6405534814f04899890a2d932db9a4985fd772fe)

Check for possible buffer overflow on very long filenames. Fixes Savannah bug 
#35525

---
diff --git a/implicit.c b/implicit.c
index 96c7b2b..c5f7481 100644
--- a/implicit.c
+++ b/implicit.c
@@ -488,6 +488,13 @@ pattern_search (struct file *file, int archive,
   dir = pathdir;
 }
+  if (stemlen > GET_PATH_MAX)
+{
+  DBS (DB_IMPLICIT, (_("Stem too long: `%.*s'.\n"),
+ (int) stemlen, stem));
+  continue;
+}
+
   DBS (DB_IMPLICIT, (_("Trying pattern rule with stem `%.*s'.\n"),
  (int) stemlen, stem));

From: bug-make-bounces+martin.dorey=hds@gnu.org 
[mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Mustapha 
Abiola
Sent: Friday, June 27, 2014 22:30
To: bug-make@gnu.org
Subject: Buffer overflow in orig/implicit.c

Kindly consider my fix for the lack of bounds checks in implicit.c




Index: make-3.82/implicit.c

===



--- make-3.82.orig/implicit.c



+++ make-3.82/implicit.c

@@ -488,6 +488,9 @@ pattern_search (struct file *file, int a



   dir = pathdir;

 }





+  if (stemlen >= PATH_MAX)

+  fatal (NILF, _("File name too long"));



+

   DBS (DB_IMPLICIT, (_("Trying pattern rule with stem `%.*s'.\n"),



  (int) stemlen, stem));







Thanks.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #44660] possible buffer overflow?

[Martin Dorey]

Follow-up Comment #1, bug #44660 (project make):

Reproduced on amd64 with up-to-the-minute make from git.  valgrind reports
things going south starting here:

martind@swiftboat:~/tmp/make-44660$ valgrind ~/download/make-git/make
==30211== Memcheck, a memory error detector
==30211== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==30211== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==30211== Command: /home/martind/download/make-git/make
==30211== 
==30211== Invalid write of size 1
==30211==at 0x4C2B614: memmove (mc_replace_strmem.c:981)
==30211==by 0x421FE5: add_hash (strcache.c:105)
==30211==by 0x41BB8D: parse_file_seq (read.c:3342)
==30211==by 0x40D222: split_prereqs (file.c:448)
==30211==by 0x41AC47: record_files (read.c:1993)
==30211==by 0x41C787: eval (read.c:1402)
==30211==by 0x41DD80: eval_makefile (read.c:446)
==30211==by 0x41E13B: read_all_makefiles (read.c:263)
==30211==by 0x407914: main (main.c:1991)
==30211==  Address 0x580c8c0 is 0 bytes after a block of size 8,176 alloc'd
==30211==at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==30211==by 0x417F98: xmalloc (misc.c:220)
==30211==by 0x4220AC: add_hash (strcache.c:63)
==30211==by 0x422218: strcache_add_len (strcache.c:207)
==30211==by 0x41B708: construct_include_path (read.c:2893)
==30211==by 0x4073ED: main (main.c:1796)

A simpler reproducer:

martind@swiftboat:~/tmp/make-44660$ cat Makefile
o : $(subst A,AA,$(subst A,,$(subst A,,$(subst
A,,;
martind@swiftboat:~/tmp/make-44660$ ruby -we 'puts(8*8*8*8*2)'
8192
martind@swiftboat:~/tmp/make-44660$ valgrind ~/download/make-git/make
==32079== Memcheck, a memory error detector
==32079== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==32079== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==32079== Command: /home/martind/download/make-git/make
==32079== 
==32079== Invalid write of size 8
==32079==at 0x4C2B5A3: memmove (mc_replace_strmem.c:981)
==32079==by 0x421FE5: add_hash (strcache.c:105)
==32079==by 0x41BB8D: parse_file_seq (read.c:3342)
==32079==by 0x40D222: split_prereqs (file.c:448)
==32079==by 0x41AC47: record_files (read.c:1993)
==32079==by 0x41C787: eval (read.c:1402)
==32079==by 0x41DD80: eval_makefile (read.c:446)
==32079==by 0x41E13B: read_all_makefiles (read.c:263)
==32079==by 0x407914: main (main.c:1991)

Remove one of the first pair of As and the crash stops happening, so it's
triggered somewhere between 4 KiB and 8 KiB.

This seems to fix that example for me:

martind@swiftboat:~/download/make-git$ git diff
diff --git a/strcache.c b/strcache.c
index 1ade5e7..7f71544 100644
--- a/strcache.c
+++ b/strcache.c
@@ -76,7 +76,7 @@ static const char *
 add_string (const char *str, unsigned int len)
 {
   char *res;
-  struct strcache *sp;
+  struct strcache *sp = NULL;
   struct strcache **spp = &strcache;
   /* We need space for the nul char.  */
   unsigned int sz = len + 1;
@@ -89,11 +89,12 @@ add_string (const char *str, unsigned int len)
   else
 /* Find the first cache with enough free space.  */
 for (; *spp != NULL; spp = &(*spp)->next)
-  if ((*spp)->bytesfree > sz)
+  if ((*spp)->bytesfree > sz) {
+sp = *spp;
 break;
+  }
 
   /* If nothing is big enough, make a new cache.  */
-  sp = *spp;
   if (sp == NULL)
 {
   sp = new_cache ();
martind@swiftboat:~/download/make-git$ 

I think it was a regression under:

Differences between revisions 9903cda2a734c2f86eefcff656aad032fbb79078 and
1454a04f81708850353dbdc0807a099c5aaab55b:

2011-02-21 07:30:11 + psm...@gnu.org
(1454a04f81708850353dbdc0807a099c5aaab55b)

* Fixups to the make man page * Minor syntax cleanups in the manual * In
non-maintainer mode set NDEBUG to disable assert() * Performance improvements
in strcache: Build Info 100020004000 3.82 
-g2.61s   8.85s   33.52s 
   3.82 -O2 1.90s   7.62s   27.82s New -g (with 
asserts)1.03s   2.31s   5.79s  
  New -O2 (no asserts)  0.65s   1.50s   3.52s

---


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #44660] possible buffer overflow?

[Martin Dorey]

Additional Item Attachment, bug #44660 (project make):

File name: strcache.c.take2.patch Size:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Using hash instead of timestamps to check for changes.

[Martin Dorey]

> I spent a few hours trying to work out how to fake this up with a
> secondary file whose "modified" time-stamp serves as "up-to-date" for
> the primary it represents.

I imagine we're not alone, but perhaps an existence proof would have some 
value: we have generic makefile code that provides this service for parts of 
our build system that generate source code.  Instead of writing rules, the 
application makefile author writes variables and the generic code $(eval)s up 
the rules.  Each rule's command gets run in a subdirectory that's uniquely 
named for each run, from where any changed results are atomically renamed over 
the targets they replace.  This gives us automatic safety against 
unsynchronized concurrent builds and protection against fail-stops where make 
is unable to remove the half-overwritten target.  The code's spattered around a 
long-feeped build system, hacked for portability and legacy cases and rife with 
excessively long bash commands, but it's not actually that large and it 
certainly didn't involve any changes to make.  While the cursory documentation 
says "Higher order code, though, is always more difficult to debug", I don't 
think th
 at's been much of a problem.  It keeps the application makefiles simple, clear 
and compliant with Dorey's first rule of writing makefiles that contain rules: 
"don't".

-Original Message-
From: bug-make-bounces+martin.dorey=hds@gnu.org 
[mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Edward 
Welbourne
Sent: Thursday, April 02, 2015 10:49
To: m...@glenstark.net
Cc: bug-make@gnu.org
Subject: Re: Using hash instead of timestamps to check for changes.

> After reading over your mail a couple of times, I realized that I hadn't
> thought things through very well.  In fact, rather than saying "hash
> instead of time", I should have said "optional additional hash check
> when timestamp has changed".

Even so, I'm unclear about why "hash" is the thing you want here.  You
anticipate saving lots of time on builds, presumably when immaterial
changes get ignored, or when the only change is to a timestamp.  (The
latter could be fixed by touch -t if it's really important.)  The
situations I've seen where that felt like it might happen have been
where some intermediate files often don't change in response to changes
in the files from which they're generated, much as a change to a comment
doesn't change the result of compiling code.

Some colleagues wrote tools with the superficially nice behaviour that,
when about to write a file, they would check to see whether it was
changed from what's already on disk; if it was unchanged, they would not
overwrite the file.  This saved regenerating files dependent on the
output file; but had the drawback that the file would stay out of date
relative to those on which *it* depended, so got remade every time we
ran make (once an irrelevant change had happened upstream).

The problem with any "is this change material" check, to evade doing
downstream build steps, is that you have to do the check on every make
run, once there is a maybe-material change present that it's saving you
from responding to.  You can use a timestamp check as a cheap pre-test
to that (file hasn't changed since last time, so can't contain a
material change) but once it *has* saved you doing some downstream work,
you are doing some checking that you must repeat each time make runs.
Something depends on something that's newer, somewhere in your
dependency tree, forcing make to re-run some of your rules, albeit these
work out that they should do a no-op.

My ideal solution to this would be to have an extra timestamp as part of
the file-system's meta-data: "up to date at" as distinct from "created"
and "modified".  (To make it generic, rather than make-specific, I'd
probably call it "validated" or some such.)  If we had this, make could
compare it, on each generated file, with "modified" on its
prerequisites; a file is out of date if a prerequisite has been modified
since it was up to date.  When regenerating a file, we could then see
whether it has changed; if it hasn't, we leave "modified" alone and
update "up to date" to the present; otherwise, we over-write the file
and change both.  I think this would do most of what I suspect you
really want.  However, file-systems don't have an extra time-stamp for
us to use in this way, so we can't do this.

Of course, we could abuse the existing time-stamps to achieve this; I
find "created" an almost useless datum - many tools create a new file to
replace the old one when "modifying", renaming the new one on success,
so the old version's creation time is forgotten and "create" is mostly
synonymous with "modify".  If we could assume that of all tools, we
could then use "creation" time as "modified" in the above and use
"modified" time as the "up to date at" time and all would swim nicely.
However, I suppose some tools really do modify files in place, so would
leave "created" unchanged w

[bug #45211] Add option to MAKEFLAGS (How to set RM variable?)

[Martin Dorey]

Follow-up Comment #1, bug #45211 (project make):

The claim being, I presume, that the second RM='' should either be RM='rm -f'
or RM='rm', the latter only being the case if changing MAKEFLAGS takes effect
implausibly quickly.  It's the former with a Debian Wheezy make 3.81 (origin
says "default"), but empty (origin says "undefined"), per the OP, with git's
4.1.90.  As you'd hope, a more normal operation is fine: it's the latter when
running make -R aka --no-builtin-variables, with either version.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make