building make 3.81 on HP-UX with bundled compiler small problem

2009-02-21 Thread Jay

GNU make 3.81 fails to compile on HP-UX 11iv1 (11.11) with the bundled K&R C 
compiler.
The error is like va_dcl unknown identifier in misc.c.
 
 
I'm using this hack to workaround:
  echo '#include '>> config.h  
 
 
 or more completely: 
  cd ${SOURCE}  
  rm -rf make-3.81  
  gzcat make-3.81.tar.gz | tar xf -  
  cd make-3.81  
  CC=cc ./configure -prefix=${PREFIX} -disable-nls -verbose -program-prefix=g  
  make config.h  
  echo '#include '>> config.h  
  make
  make install
  cd ..
  rm -rf make-3.81 || true
 

(and then I use gmake thereafter)


  - Jay

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


Satellite TV hex files for Funcards, Goldcards

2002-10-09 Thread Jay



 
Hello there 
 
Did you know that you can program smart 
cards with files from the internet and open lots of pay per view chanells
for 
your televisual pleasure.  
   
 
Take a look at http://MagicFun.da.ru for the latest hex 
files.  
   
 
Many thanks Jay.  


make 3.81 crash: make: double free or corruption (!prev)

2008-01-28 Thread J Jay
$ 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


[bug #37703] job starts before dependency

2013-07-09 Thread Jay Lawrence
Follow-up Comment #5, bug #37703 (project make):

I am seeing a very similar scenario with 3.82. 

I have also downloaded the latest source and see the same issue.

When a very complex parallel build runs, and intermediate archive is
generated, and some executables that depend on that archive are built before
that parallel job completes. If I immediately reinvoke make with the same
command line, it does then relink the executables.

There is no "patch" information in this bug. Can you let me know what the
change was so that I can verify that it is in the source code release I am
building?

Thanks,

Jay

___

Reply to this item at:

  <http://savannah.gnu.org/bugs/?37703>

___
  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: [bug #37703] job starts before dependency

2013-07-09 Thread Jay Lawrence
My bad, I see that patch now, please disregard...

Jay

-Original Message-
From: Jay Lawrence [mailto:invalid.nore...@gnu.org] 
Sent: Tuesday, July 09, 2013 10:36 AM
To: Paul D. Smith; Koen Van Hoof; Martijn Vermaat; Jay Lawrence; 
bo...@kolpackov.net; bug-make@gnu.org
Subject: [bug #37703] job starts before dependency

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

I am seeing a very similar scenario with 3.82. 

I have also downloaded the latest source and see the same issue.

When a very complex parallel build runs, and intermediate archive is generated, 
and some executables that depend on that archive are built before that parallel 
job completes. If I immediately reinvoke make with the same command line, it 
does then relink the executables.

There is no "patch" information in this bug. Can you let me know what the 
change was so that I can verify that it is in the source code release I am 
building?

Thanks,

Jay

___

Reply to this item at:

  <http://savannah.gnu.org/bugs/?37703>

___
  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: [bug #37703] job starts before dependency

2013-07-21 Thread Jay Lawrence
Turned out to be a Makefile problem.

Deep in an included Makefile was a
.SECONDARY:
with no pre-requisites.

As documented, this causes chain-rules to behave differently.

I had rules that went from .c->.o->.a
Then an executable that linked a bunch of these .a's together.

The scenario I was seeing was
- build everything in parallel
- remove one of the .a files
- build from the root, and see the .a rebuild, the executable did not 
relink
- invoke make again and the executable relinks

I'm still not absolutely sure why the .SECONDARY caused this behavior, but when 
I removed it make behaves perfectly.

FYI, I'm reworking a serial build that takes about 2 hours into a parallel 
build based on the methodology espoused in 
http://www.cmcrossroads.com/article/painless-non-recursive-make. So far so 
good, I have about a 20 minute hunk of it that now builds in 1 minute 30 
seconds on a 24 core machine. Non-linear, but not that far off. This product 
has been around for 20 years and we are a classic example of the badness of 
recursive builds, and we have tried to support multiple 'make' systems with a 
common set of makefiles. I've seen the light and (to quote you) am "moving to a 
portable make instead of portable makefiles". I last rewrote these Makefiles in 
1998, it is time for an upgrade.

Jay LAwrence

-Original Message-
From: Paul Smith [mailto:psm...@gnu.org] 
Sent: Sunday, July 21, 2013 12:18 AM
To: Jay Lawrence
Cc: 'Koen Van Hoof'; 'Martijn Vermaat'; bo...@kolpackov.net; bug-make@gnu.org
Subject: Re: [bug #37703] job starts before dependency

On Tue, 2013-07-09 at 10:43 -0400, Jay Lawrence wrote:
> My bad, I see that patch now, please disregard...

In your comment below you mentioned you'd tried the latest source but it still 
failed.  I believe I fixed this bug with a commit in April.  Can you reproduce 
the issue with the latest source code; for example, the
RC1 source package?

> I am seeing a very similar scenario with 3.82. 
> 
> I have also downloaded the latest source and see the same issue.
> 
> When a very complex parallel build runs, and intermediate archive is 
> generated, and some executables that depend on that archive are built 
> before that parallel job completes. If I immediately reinvoke make 
> with the same command line, it does then relink the executables.
> 
> There is no "patch" information in this bug. Can you let me know what 
> the change was so that I can verify that it is in the source code 
> release I am building?




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


Make regression in 4.0-8.1 (from Debian stable)

2015-11-26 Thread Jay Aurabind
Hi,

Recently I was setting up an android build server on debian 8.2. The
make version in the repo is 4.0-8.1. There is a regression relating to
parallel builds.

Make 3.81 will finish the build in 27 minutes. With the same
conditions for make 4, it takes 1 hour.


Is this  a known issue  ?

-- 

Thanks and Regards,
Aurabindo J

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


Bug/feature?: test -f gives an error

2000-08-30 Thread Jay Vaishnav

Hi,

I am enclosing the rule for making a target from a GNU make
file that I have written.

SHELL = /bin/sh

# Check if the present working directory contains any Java sources.
local:  
listjava='$(wildcard *.java)';if test -f $(firstword $$listjava); \
then javac $$listjava; fi

If the present working directory does not contain any files
with the extension '.java', then listjava evaluates to the 
empty string and gnu make gives the following error.

/bin/sh: test: argument expected
gmake: *** [local] Error 1

While gmake does continue the execution of the recursive tree
walk, the presence of this error for all those non-leaf level
directories that do not contain Java sources is distracting.

If this is a feature of gnu make, would you be kind enough to
suggest a workaround that eliminates this unsightly error from
the log file generated for the make?

Thanks very much.

jay

Jay Vaishnav
Chingari, Inc. http://www.chingari.com/  
1032 Elwell Court, Suite 111
Palo Alto, CA 94303 

Cell: (408) 396-5356
Work: (650) 254-0565 x224
Fax : (650) 254-0566 





[bug #16145] .SECONDARY: prevents non-existent dependency from forcing rebuild

2006-03-21 Thread Jay Berkenbilt

URL:
  

 Summary: .SECONDARY: prevents non-existent dependency from
forcing rebuild
 Project: make
Submitted by: jayberkenbilt
Submitted on: Tue 03/21/06 at 20:29
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
   Component Version: CVS
Platform Version: None
   Fixed Release: None

___

Details:

This is with 3.81rc2 as checked out of CVS on March 21, 2006.

With the following makefile:

# --
ifdef BREAK_MAKE
.SECONDARY:
endif

all: a.2

a.1:
touch a.1

a.2: a.1 a.h

a.h:

%.2: %.1
touch $@

clean:
rm a.1 a.2
# --

running make once causes a.1 and a.2 to be updated, and running make
subsequently causes a.2 to be updated as expected because a.2 depends upon
the non-existent a.h, and a.h has a target with no dependencies and no rules.
 (This is normal for automatically generated dependency files.)  make -d -rR
on a subsequent run shows the following output with 3.81rc2 (without
BREAK_MAKE defined):

GNU Make 3.81rc2
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-redhat-linux-gnu
Reading makefiles...
Reading makefile `/tmp/m'...
Updating makefiles
 Considering target file `/tmp/m'.
  Looking for an implicit rule for `/tmp/m'.
  No implicit rule found for `/tmp/m'.
  Finished prerequisites of target file `/tmp/m'.
 No need to remake target `/tmp/m'.
Updating goal targets
Considering target file `all'.
 File `all' does not exist.
 Looking for an implicit rule for `all'.
 No implicit rule found for `all'.
  Considering target file `a.2'.
   Looking for an implicit rule for `a.2'.
   Trying pattern rule with stem `a'.
   Trying implicit prerequisite `a.1'.
   Found an implicit rule for `a.2'.
Considering target file `a.1'.
 Finished prerequisites of target file `a.1'.
No need to remake target `a.1'.
Pruning file `a.1'.
Considering target file `a.h'.
 File `a.h' does not exist.
 Looking for an implicit rule for `a.h'.
 No implicit rule found for `a.h'.
 Finished prerequisites of target file `a.h'.
Must remake target `a.h'.
Successfully remade target file `a.h'.
   Finished prerequisites of target file `a.2'.
   Prerequisite `a.1' is older than target `a.2'.
   Prerequisite `a.1' is older than target `a.2'.
   Prerequisite `a.h' of target `a.2' does not exist.
  Must remake target `a.2'.
touch a.2
Putting child 0x096823f8 (a.2) PID 14360 on the chain.
Live child 0x096823f8 (a.2) PID 14360 
Reaping winning child 0x096823f8 PID 14360 
Removing child 0x096823f8 PID 14360 from chain.
  Successfully remade target file `a.2'.
 Finished prerequisites of target file `all'.
Must remake target `all'.
Successfully remade target file `all'.

The output is identical with 3.80 except for cosmetic differences.

With BREAK_MAKE defined (i.e., an empty .SECONDARY: rule), the results are
the same with 3.80, but 3.81rc2 (and 3.81rc1 as well) generate this with make
-d -rR BREAK_MAKE=1:

GNU Make 3.81rc2
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-redhat-linux-gnu
Reading makefiles...
Reading makefile `/tmp/m'...
Updating makefiles
 Considering target file `/tmp/m'.
  Looking for an implicit rule for `/tmp/m'.
  No implicit rule found for `/tmp/m'.
  Finished prerequisites of target file `/tmp/m'.
 No need to remake target `/tmp/m'.
Updating goal targets
Considering target file `all'.
 File `all' does not exist.
 Looking for an implicit rule for `all'.
 No implicit rule found for `all'.
  Considering target file `a.2'.
   Looking for an implicit rule for `a.2'.
   Trying pattern rule with stem `a'.
   Trying implicit prerequisite `a.1'.
   Found an implicit rule for `a.2'.
Considering target file `a.1'.
 Finished prerequisites of target file `a.1'.
No need to remake target `a.1'.
Pruning file `a.1'.
Looking for an implicit rule for `a.h'.
No implicit rule found for `a.h'.
   Finished prerequisites of target file `a.2'.
   Prerequisite `a.1' is older than target `a.2'.
   Prerequisite `a.1' is older than target `a.2'.
   Prerequisite `a.h' of target `a.2' does not exist.
  No need to remake target `a.2'.
 Finished prerequisites of target file `all'.
Must remake target `all'.
Successfully remade target file `all'.
make: Nothing to be done for `all'.

Observe that make recognizes that a.h does not exist, but then still 

[bug #16145] .SECONDARY: prevents non-existent dependency from forcing rebuild

2006-03-21 Thread Jay Berkenbilt

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

Either of your proposed solutions will work fine for me, and the first one
(mentioning things explicitly to prevent them from being removed) is what
I've done for years and was doing until I decided that, after having been
using gnu make for 10 years, it was time to reread the documentation all the
way through see what new features  had been introduced! I failed to realize
that one of the side effects of a target being declared secondary is that
make doesn't consider it out of date when it doesn't exist, but when I think
about it, that's pretty obviously the correct behavior since otherwise every
build would end up regenerating it  if it disappeared.

I can't convince you that I need a global .SECONDARY because I don't believe
it myself now that I actually correctly understand what it does. :-)  I
generally prefer to have my intermediate targets stick around, but there are
ways to make this happen, as you pointed out.  Actually, I don't think my
current build system has any implicit intermediate targets at the moment
since it invokes make with -rR anyway, though I might have coded some chain
of implicit rules at some point and forgotten about it.  No matter though.

Thanks for the prompt responses.  I consider this issue resolved.  Feel free
to close it.


___

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 #16145] .SECONDARY: prevents non-existent dependency from forcing rebuild

2006-03-27 Thread Jay Berkenbilt

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

Okay, I've studied this and agree with your analysis that it is working as
intended. Unfortunately, this seems to leave me without any ability to tell
make not to delete intermediate targets without also telling it not to try to
rebuild things that have dependencies that don't exist.  Am I missing
something?  Thanks for the pointer to the other bug, which I missed in my
search for other bugs relating to this 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


overzealous @command within canned command sequence in 3.79.1

2001-06-22 Thread E. Jay Berkenbilt


With the following Makefile:


define thing
echo 1
@echo 2
echo 3
endef

test:
$(thing)


run make.  In version 3.79.1, the output is

echo 1
1
2
3

In version 3.77, the output is the expected

echo 1
1
2
echo 3
3

The behavior in 3.79.1 does not agree with the behavior described in
the manual in the mode "Defining Canned Command Sequences" as quoted
below:

> In command execution, each line of a canned sequence is treated just
>  as if the line appeared on its own in the rule, preceded by a tab.  In
>  particular, `make' invokes a separate subshell for each line.  You can
>  use the special prefix characters that affect command lines (`@', `-',
>  and `+') on each line of a canned sequence.  *Note Writing the Commands
>  in Rules: Commands.  For example, using this canned sequence:
>
>   define frobnicate
>   @echo "frobnicating target $@"
>   frob-step-1 $< -o $@-step-1
>   frob-step-2 $@-step-1 -o $@
>   endef
>
>  `make' will not echo the first line, the `echo' command.  But it _will_
>  echo the following two command lines.
>
> On the other hand, prefix characters on the command line that refers
>  to a canned sequence apply to every line in the sequence.  So the rule:
>
>   frob.out: frob.in
>   @$(frobnicate)
>
>  does not echo _any_ commands.  (*Note Command Echoing: Echoing, for a
>  full explanation of `@'.)

Based on what happens with slightly more complex examples, it seems
that once the first @command is encountered within a canned command
sequence, no further commands are echoed within the rest of the
command sequence.  For example, the following:


define thing
echo 1
@echo 2
echo 3
endef

all: test1 test2

test1:
$(thing)
echo 4

test2:
echo 5


results in

echo 1
1
2
3
echo 4
4
echo 5
5

I have not investigated further or looked at the source.  I also have
no built versions of make between 3.77 and 3.79.1 to test against.
Please let me know if you are unable to reproduce this bug so I can
investigate further.

My version of gnu make 3.79.1 is as distributed with RedHat Linux 7.1,
ix86.

--
E. Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/

___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make