[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

2021-07-21 Thread Mike Frysinger 
Follow-up Comment #1, bug #60774 (project make):

i thought i had included it originally, but i think it might be a change in
the kernel version.  i'm testing against linux-5.10 & glibc-2.31.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

2021-06-11 Thread Mike Frysinger 
URL:
  

 Summary: make hangs on fcntl lock when using -O and stdout is
/dev/null
 Project: make
Submitted by: vapier
Submitted on: Fri 11 Jun 2021 06:24:02 PM EDT
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

i can reproduce this with make 4.2.1, 4.3, and current git
(012918bf11fbc2a94dc2319d15d05595c351b811) on Debian/Ubuntu systems.  my
reproduction:

$ wget https://busybox.net/downloads/busybox-1.32.1.tar.bz2
$ tar xf busybox-1.32.1.tar.bz2
$ cd busybox-1.32.1
# This works fine.
$ make -O -j32 defconfig
# This hangs indefinitely.
$ make -O -j32 defconfig >/dev/null

gdb shows the hang in:

(gdb) bt
#0  0x7f10555c9643 in fcntl64 () from /lib64/libc.so.6
#1  0x002225ff in acquire_semaphore () at output.c:267
#2  output_dump (out=out@entry=0x13a9744) at output.c:368
#3  0x0021b43a in reap_children (block=block@entry=0x1, err=, err@entry=0x0) at job.c:937
#4  0x00227c99 in update_goal_chain (goaldeps=) at
remake.c:112
#5  0x0021fa1b in main (argc=0x5, argv=0x7ffdd42b3478,
envp=0x7ffdd42b34a8) at main.c:2558

(gdb) f 1
#1  0x002225ff in acquire_semaphore () at output.c:267
267   if (fcntl (sync_handle, F_SETLKW, ) != -1)

(gdb) list
262
263   fl.l_type = F_WRLCK;
264   fl.l_whence = SEEK_SET;
265   fl.l_start = 0;
266   fl.l_len = 1;
267   if (fcntl (sync_handle, F_SETLKW, ) != -1)
268 return 
269   perror ("fcntl()");
270   return NULL;
271 }

strace confirms it:
286807 fcntl(1, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
l_len=1}

full strace log attached in case it helps.



___

File Attachments:


---
Date: Fri 11 Jun 2021 06:24:02 PM EDT  Name: log.xz  Size: 443KiB   By: vapier



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[PATCH] manual: relocate $? example

2021-03-24 Thread Mike Frysinger 
The $? example shows up after all the automatic variables are discussed.
This is weird as it's only relevant to the $? section, and the content
that follows it is relevant to all the automatic variables.

Move it up to the $? specific section.
---
 doc/make.texi | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/doc/make.texi b/doc/make.texi
index 60c75d600b79..45d3cec7aecc 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -10243,6 +10243,18 @@ The names of all the prerequisites that are newer than 
the target, with
 spaces between them.  If the target does not exist, all prerequisites
 will be included.  For prerequisites which are archive members, only the
 named member is used (@pxref{Archives}).
+
+@samp{$?} is useful even in explicit rules when you wish to operate on only
+the prerequisites that have changed.  For example, suppose that an archive
+named @file{lib} is supposed to contain copies of several object files.
+This rule copies just the changed object files into the archive:
+
+@example
+@group
+lib: foo.o bar.o lose.o win.o
+ar r lib $?
+@end group
+@end example
 @cindex prerequisites, list of changed
 @cindex list of changed prerequisites
 
@@ -10299,18 +10311,6 @@ If the target name in an explicit rule does not end 
with a recognized
 suffix, @samp{$*} is set to the empty string for that rule.
 @end table
 
-@samp{$?} is useful even in explicit rules when you wish to operate on only
-the prerequisites that have changed.  For example, suppose that an archive
-named @file{lib} is supposed to contain copies of several object files.
-This rule copies just the changed object files into the archive:
-
-@example
-@group
-lib: foo.o bar.o lose.o win.o
-ar r lib $?
-@end group
-@end example
-
 Of the variables listed above, four have values that are single file
 names, and three have values that are lists of file names.  These
 seven have variants that get just the file's directory name or just
-- 
2.30.2

[bug #49773] release/archive older make manuals

2016-12-05 Thread Mike Frysinger 
URL:
  

 Summary: release/archive older make manuals
 Project: make
Submitted by: vapier
Submitted on: Mon 05 Dec 2016 06:15:27 PM GMT
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

some GNU projects will version their manuals so that it's easy to go back in
time and compare versions, especially when the system you're using isn't
running the very latest versions

for example, autoconf does:
https://www.gnu.org/software/autoconf/manual/autoconf-2.67/
https://www.gnu.org/software/autoconf/manual/autoconf-2.68/
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/

and the default is to just link to the latest version.

could we get something similar for make ?  many "current" or "lts" distros are
still running make 3.81/3.82.




___

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

[PATCH] manual: relocate $? example

2016-05-25 Thread Mike Frysinger 
The $? example shows up after all the automatic variables are discussed.
This is weird as it's only relevant to the $? section, and the content
that follows it is relevant to all the automatic variables.

Move it up to the $? specific section.
---
 doc/make.texi | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/doc/make.texi b/doc/make.texi
index 01bcec7..e10c84e 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -9902,6 +9902,18 @@ implicit rule (@pxref{Implicit Rules}).
 The names of all the prerequisites that are newer than the target, with
 spaces between them.  For prerequisites which are archive members, only
 the named member is used (@pxref{Archives}).
+
+@samp{$?} is useful even in explicit rules when you wish to operate on only
+the prerequisites that have changed.  For example, suppose that an archive
+named @file{lib} is supposed to contain copies of several object files.
+This rule copies just the changed object files into the archive:
+
+@example
+@group
+lib: foo.o bar.o lose.o win.o
+ar r lib $?
+@end group
+@end example
 @cindex prerequisites, list of changed
 @cindex list of changed prerequisites
 
@@ -9958,18 +9970,6 @@ If the target name in an explicit rule does not end with 
a recognized
 suffix, @samp{$*} is set to the empty string for that rule.
 @end table
 
-@samp{$?} is useful even in explicit rules when you wish to operate on only
-the prerequisites that have changed.  For example, suppose that an archive
-named @file{lib} is supposed to contain copies of several object files.
-This rule copies just the changed object files into the archive:
-
-@example
-@group
-lib: foo.o bar.o lose.o win.o
-ar r lib $?
-@end group
-@end example
-
 Of the variables listed above, four have values that are single file
 names, and three have values that are lists of file names.  These seven
 have variants that get just the file's directory name or just the file
-- 
2.8.2


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

[bug #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

2010-08-10 Thread Mike Frysinger 

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

yes, that patch fixes things for me.  now i get the expected:
Makefile:240: *** mixed implicit and normal rules.  Stop.

but that is something to take up with glibc maintainers

___

Reply to this item at:

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

___
  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 #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

2010-08-09 Thread Mike Frysinger 

URL:
  http://savannah.gnu.org/bugs/?30723

 Summary: implicit re-executing of subdirs breaks $(origin)
with make-3.82
 Project: make
Submitted by: vapier
Submitted on: Tue 10 Aug 2010 05:22:11 AM GMT
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

upgrading from make-3.81 to make-3.82 seems to break the origin marking of
variables and thus command line variable overriding.  using glibc here as my
example.

to reproduce (warning: do not run as root):
  tar xf glibc-2.11.2.tar.bz2
  cd glibc-2.11.2
  mkdir build
  cd build
  ../configure --prefix=/usr -q
  sed -i '/^install_root/{h;s:.*:$(warning install_root=$(install_root)
origin=$(origin install_root)):;H;x;H;x}' config.make
  make install-headers install_root=$PWD/foo

the local config.make file has a default:
install_root =
but we're overriding it on the command line, so that should always be
ignored

glibc will basically do a `make -C ..`, and here you'll see the correct
behavior:
.../config.make:8: install_root=$PWD/foo origin=command line
.../config.make:10: install_root=$PWD/foo origin=command line

but the makefile logic in there depends on generated files.  so make will
generate those files, leave the subdir, and then re-enter it.  upon re-entry
though, we now see:
.../config.make:8: install_root=$PWD/foo origin=environment
.../config.make:10: install_root= origin=file

obviously that is incorrect ;)




___

Reply to this item at:

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

___
  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 #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

2010-08-09 Thread Mike Frysinger 

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

i tried to recreate a reduced test case but failed, but then i realized i was
testing on a diff machine that had make-3.81

here is a simple reduced test case ... forget about glibc ;)

$ tar xf origin-breakage.tar.bz2
$ cd origin-breakage
$ make-3.82 x=1
config.make:1: x=1 origin=command line
config.make:3: x=1 origin=command line
rm -f foo/foo
make-3.82 -C foo
make-3.82[1]: Entering directory `/home/vapier/origin-breakage/foo'
../config.make:1: x=1 origin=command line
../config.make:3: x=1 origin=command line
Makefile:2: foo: No such file or directory
touch foo
make-3.82[1]: Leaving directory `/home/vapier/origin-breakage/foo'
make-3.82[1]: Entering directory `/home/vapier/origin-breakage/foo'
../config.make:1: x=1 origin=environment
../config.make:3: x= origin=file
make-3.82[1]: `foo' is up to date.
make-3.82[1]: Leaving directory `/home/vapier/origin-breakage/foo'
rm -f foo/foo

$ make-3.81 x=1
config.make:1: x=1 origin=command line
config.make:3: x=1 origin=command line
rm -f foo/foo
make-3.81 -C foo
make-3.81[1]: Entering directory `/home/vapier/origin-breakage/foo'
../config.make:1: x=1 origin=command line
../config.make:3: x=1 origin=command line
Makefile:2: foo: No such file or directory
touch foo
make-3.81[1]: Leaving directory `/home/vapier/origin-breakage/foo'
make-3.81[1]: Entering directory `/home/vapier/origin-breakage/foo'
../config.make:1: x=1 origin=command line
../config.make:3: x=1 origin=command line
make-3.81[1]: `foo' is up to date.
make-3.81[1]: Leaving directory `/home/vapier/origin-breakage/foo'
rm -f foo/foo

___

Reply to this item at:

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

___
  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 #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

2010-08-09 Thread Mike Frysinger 

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

File name: origin-breakage.tar.bz2Size:0 KB


___

Reply to this item at:

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

___
  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 #27714] expansion of $(shell) in target forces serialization of targets

2009-10-19 Thread Mike Frysinger 

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

i dont really know how GNU make is architected, but i dont see why make cant
fork the process to handle the target and then the subprocess does both
deferred expansion and running the commands listed for that target.

i'd also point out that other make implementations (such as BSD makes) handle
this the way i expect -- in parallel.

___

Reply to this item at:

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

___
  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 #27714] expansion of $(shell) in target forces serialization of targets

2009-10-18 Thread Mike Frysinger 

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

i understand what you're saying, but i think the behavior you describe as
expected is actually a bug.  deferred variable expansion for a target
shouldnt affect make's ability to run other targets.

___

Reply to this item at:

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

___
  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 #27714] expansion of $(shell) in target forces serialization of targets

2009-10-16 Thread Mike Frysinger 

URL:
  http://savannah.gnu.org/bugs/?27714

 Summary: expansion of $(shell) in target forces
serialization of targets
 Project: make
Submitted by: vapier
Submitted on: Fri 16 Oct 2009 07:50:48 AM GMT
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

i noticed a package recently that would build serially even when i gave it -j
(on a quad machine).  looking into it, the reason was that $(shell) was
appended to a compiler flag leading to it being expanded when the target was
run:
CFLAGS += $(shell .)

forcing the $(shell) to be evaluated immediately allowed things to build in
parallel:
SOME_CHECK := $(shell .)
CFLAGS += $(SOME_CHECK)

behavior is seen with make-3.80 and make-3.81

here is a simple example:
$ cat makefile
t = 0 a b c 1 d e f 2 g h i 3 j k l 4 m n o 5 p q r 6
all: $(t)
@echo
$(t):
@printf $@ $(shell :)

$ while make -f makefile -j ; do : ; done
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jkl4mno5pqr6

removing the $(shell :) allows for parallel evaluation:
0abc1de2gi3hjkl4mnoqr56p
0abc1de2ghi3jkl4mn5pqor6
0acde21gbhi3jkl4mno5pqr6
0abc1de2ghi3jkl4mn5qr6po
0abc1d2gehi3jkl4o5mpnqr6
0abc1de2ghi3jkl4mno5pq6r
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jl4n5pkqorm6
0abc1de2ghi3jkl4mno5pqr6
0abc1de2ghi3jkl4mnpqor56




___

Reply to this item at:

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

___
  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 #16652] typo in make(1) manpage in cvs / 3.81

2006-05-21 Thread Mike Frysinger 

URL:
  http://savannah.gnu.org/bugs/?func=detailitemitem_id=16652

 Summary: typo in make(1) manpage in cvs / 3.81
 Project: make
Submitted by: vapier
Submitted on: Montag 22.05.2006 um 04:55
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
   Component Version: CVS
Operating System: Any
   Fixed Release: None

___

Details:

current manpage has a slight typo when describing the -f flag ... it has a
leading '+' which is not needed:

--- make.1
+++ make.1
@@ -164,7 +164,7 @@ for debugging while remaking makefiles.
 Give variables taken from the environment precedence
 over variables from makefiles.
 .TP 0.5i
-+\fB\-f\fR \fIfile\fR, ...
+\fB\-f\fR \fIfile\fR, ...
 Use
 .I file
 as a makefile.







___

Reply to this item at:

  http://savannah.gnu.org/bugs/?func=detailitemitem_id=16652

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



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

Re: change in SHELL behavior: feature, right ?

2006-04-19 Thread Mike Frysinger 
On Wednesday 19 April 2006 08:18, Paul D. Smith wrote:
 %% Mike Frysinger [EMAIL PROTECTED] writes:
   mf so the question is, should gcc be making sure that the shell
   mf scripts that use SHELL pull the value from configure ?  or is make
   mf broken ?

 Make is not broken: this behavior WRT SHELL is mandated by the POSIX
 standard.

 There are various things you could do to resolve the issue:

right ... i just wanted to double check that it is indeed gcc at fault before 
i dig through the build system to fix it

thanks
-mike


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