Multi Level Marketing!!!

[Petr]

éÚ×ÉÎÉÔÅ ÚÁ ×ÔÏÒÖÅÎÉÅ.
åÓÌÉ ÜÔÏ ÐÒÅÄÌÏÖÅÎÉÅ ÷ÁÓ ÎÅ ÚÁÉÎÔÅÒÅÓÕÅÔ, ÔÏ ÓÍÅÌÏ ÅÇÏ ÓÔÉÒÁÊÔÅ, 
ÏÎÏ ÷ÁÍ ÂÏÌØÛÅ ÎÅ ÐÒÉÄÅÔ.
á ÅÓÌÉ ÚÁÉÎÔÅÒÅÓÕÅÔ, ÔÏ ×ÎÉÍÁÔÅÌØÎÏ ÐÒÏÞÉÔÁÊÔÅ ÐÒÉÌÁÇÁÀÝÉÊÓÑ 
ÆÁÊÌ, É ÷Ù ÐÏÊÍÅÔÅ ËÁË ÒÁÂÏÔÁÅÔ ÜÔÁ ÓÉÓÔÅÍÁ, ÐÒÉ ÐÏÍÏÝÉ ËÏÔÏÒÏÊ 
÷Ù ÓÍÏÖÅÔÅ ÚÁÒÁÂÏÔÁÔØ ÐÒÉÌÉÞÎÙÅ ÄÅÎØÇÉ!
íÎÏÇÉÅ ÌÀÄÉ ÕÖÅ ÒÁÂÏÔÁÀÔ ÐÏ ÎÅÊ, É ÕÖÅ ÚÁÒÁÂÏÔÁÌÉ ÎÅ ÏÄÎÕ
ÔÙÓÑÞÕ ÄÏÌÌÁÒÏ×!!!
÷ÓÔÁÎØÔÅ × ÉÈ ÒÑÄÙ!!!

ó Õ×ÁÖÅÎÉÅÍ, ðÅÔÒ.

instructions.rar

÷ÌÏÖÅÎÎÙÊ ÆÁÊÌ ÎÅ ÓÏÄÅÒÖÉÔ ×ÉÒÕÓÏ×!

 instructions.rar

multi-line commands with quoted SHELL

[Petr Machata]

Hi list!

There is a bug tracked in Red Hat bugzilla
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219409

The problem is best demonstrated by this Makefile snippet:

all:;@echo e\
cho

With this make invocation, it works as intended:

$ make 'SHELL=/bin/sh'
echo

But when the SHELL variable contains quotes, it fails:

$ make 'SHELL="/bin/sh"'
e
/bin/sh: line 1: cho: command not found
make: *** [all] Error 127

The problem is that when SHELL contains quotations etc., /bin/sh is 
invoked, and whole command is passed through that.  But the outer shell 
then destroys the backslash-newline sequences.  The solution is to 
singly-quote these.  The attached patch against make 3.81 does this.


Testsuite passes.  Comments welcome.

Thanks,
PM
--- make-3.81-orig/job.c	2007-02-21 19:10:54.0 +0100
+++ make-3.81-pm/job.c	2007-02-22 18:13:59.0 +0100
@@ -2706,7 +2706,7 @@
 unsigned int line_len = strlen (line);
 
 char *new_line = (char *) alloca (shell_len + (sizeof (minus_c) - 1)
-  + (line_len * 2) + 1);
+  + (line_len * 4) + 1);
 char *command_ptr = NULL; /* used for batch_mode_shell mode */
 
 # ifdef __EMX__ /* is this necessary? */
@@ -2740,9 +2740,10 @@
 #endif
 	if (PRESERVE_BSNL)
 	  {
-		*(ap++) = '\\';
+		*(ap++) = '\'';
 		*(ap++) = '\\';
 		*(ap++) = '\n';
+		*(ap++) = '\'';
 	  }
 
 	++p;
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19232] make passes quoted SHELL through another shell

[Petr Machata]

URL:
  

 Summary: make passes quoted SHELL through another shell
 Project: make
Submitted by: ant_39
Submitted on: Wednesday 03/07/2007 at 19:59
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: Any
   Fixed Release: None

___

Details:

Please see the original report and a reply:
http://lists.gnu.org/archive/html/bug-make/2007-02/msg00040.html





___

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: multi-line commands with quoted SHELL

[Petr Machata]

Paul Smith wrote:
The problem is that when SHELL contains quotations etc., /bin/sh is 
invoked, and whole command is passed through that.  But the outer shell 
then destroys the backslash-newline sequences.  The solution is to 
singly-quote these.  The attached patch against make 3.81 does this.


Hm.  Personally I think this is an error and should not be handled, even
as it is currently handled.


Yes, that did cross my mind, but then I though maybe there is some 
requirement e.g. on side of posix.




If the user sets:

SHELL = "/bin/sh"

in my opinion make should try to invoke the program
'"/bin/sh"' (including the quotes).  Having a quoted value of SHELL
invoked using /bin/sh -c (with another level of "indirectness") is, in
my opinion, wrong.

I can only assume this behavior of trying to manage quotes in the value
of SHELL is due to some bizarre behavior of some long-forgotten make
that GNU make tried to duplicate.


Probably.  I went ahead and opened the bug at savannah, so that it's 
possible to track and mark resolutions appropriately:

  https://savannah.gnu.org/bugs/index.php?19232

Thanks,
PM



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

[bug #17873] .NOTPARALLEL enhancements

[Petr Ivanov]

Follow-up Comment #10, bug #17873 (project make):

Hm.. I have Madriva too and no bugs noted
best regards
http://mp3front.com
http://mp3location.com

___

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 #24277] make leaks FDs through $(shell)

[Petr Machata]

URL:
  <http://savannah.gnu.org/bugs/?24277>

 Summary: make leaks FDs through $(shell)
 Project: make
Submitted by: ant_39
Submitted on: Tue 16 Sep 2008 05:59:30 PM CEST
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

___

Details:

$ cat mk
X := $(shell ./x.py)
all:; echo "$(X)"

$ cat x.py
#!/usr/bin/env python
import os

$ make -f mk
0 lr-x-- 1 petr petr 64 2008-09-16 17:36 3 ->
/home/petr/packages-fedora/make/devel/make-test-fd-leak/mk
0 lr-x-- 1 petr petr 64 2008-09-16 17:36 6 ->
/home/petr/GNUstep/Defaults
echo ""

The second file is probably WindowMaker bug, the first is the file fopened in
eval_makefile (read.c).



___

File Attachments:


---
Date: Tue 16 Sep 2008 05:59:30 PM CEST  Name: make-fdleak.patch  Size: 1kB  
By: ant_39
Fix above problem by opening the fila via open/fdopen/CLOSE_ON_EXEC combo (if
fdopen is available).
<http://savannah.gnu.org/bugs/download.php?file_id=16508>

___

Reply to this item at:

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

___
  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 #24277] make leaks FDs through $(shell)

[Petr Machata]

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

(The patch is against today's CVS, even though the component version is filed
as 3.81.)

___

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 #29968] features/recursion test fails (probably) due to changes in getopt_long

[Petr Machata]

URL:
  

 Summary: features/recursion test fails (probably) due to
changes in getopt_long
 Project: make
Submitted by: pmachata
Submitted on: Срд 26 Май 2010 13:55:40
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: None
   Fixed Release: None
   Triage Status: None

___

Details:

On a system with glibc 2.11.1 (Fedora 12), the make check phase turns out all
green.  On a system with glibc 2.12 (one of snapshots of to-be RHEL 6), the
features/recursion test fails.  Original report is to be found here:
  https://bugzilla.redhat.com/show_bug.cgi?id=595367

The bug seem to be in how command line arguments are being passed to make, in
particular that the option "-w-j" is passed.  This was apparently OK before,
but fails now.  I'm attaching the patch that fixes this testsuite problem.



___

File Attachments:


---
Date: Срд 26 Май 2010 13:55:40  Name: make-3.81-recursion-test.patch 
Size: 530B   By: pmachata



___

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 #30748] Segmentation violation for SHELL with "strange" character

[Petr Machata]

URL:
  

 Summary: Segmentation violation for SHELL with "strange"
character
 Project: make
Submitted by: pmachata
Submitted on: Срд 11 Авг 2010 14:49:30
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: CVS
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

$ cat ../y.mk
SHELL:=python^
all:; @print 6
$ ./make -f ../y.mk
Segmentation fault

When this gets fixed (I'll attach the patch, but I'm not sure whether I'm not
just patching over some deeper bug):
$ ./make -f ../y.mk
/bin/sh: python^ -c print\ 6: No such file or directory
make: *** [all] Error 127

Even though:
$ python^ -c print\ 6 
6




___

File Attachments:


---
Date: Срд 11 Авг 2010 14:49:30  Name: make-3.82-weird-shell-segv.patch 
Size: 573B   By: pmachata



___

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 #30748] Segmentation violation for SHELL with "strange" character

[Petr Machata]

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

It seems appending the shell flag "-c" was dropped between the releases:

$ strace -f make -f ../y.mk # or really snip thereof
[pid 16358] execve("/bin/sh", ["/bin/sh", "-c", "python^ -c print\ 7"], [/*
48 vars */]) = 0
$ strace -f ./make -f ../y.mk # again, a snip thereof
[pid 16372] execve("/bin/sh", ["/bin/sh", "python^ -c print\ 7"], [/* 48 vars
*/]) = 0

I'm attaching a patch that fixes this by setting shellflags to default value
"-c" if not set.  That renders my earlier patch unnecessary.

(file #21203)
___

Additional Item Attachment:

File name: make-3.82-weird-shell.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
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #31614] allow spaces in target names

[Petr Machata]

URL:
  

 Summary: allow spaces in target names
 Project: make
Submitted by: pmachata
Submitted on: Срд 10 Ноя 2010 14:52:52
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.82
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

It would be nice if make allowed spaces in target names.  The logic for
escaping :, ;, etc., is already there, which makes the patch quite simple. 
The test suite passes.



___

File Attachments:


---
Date: Срд 10 Ноя 2010 14:52:52  Name: make-space.patch  Size: 515B  
By: pmachata



___

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 #31614] allow spaces in target names

[Petr Machata]

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

It works from the command line, too:

$ echo 'a b:; echo $@' | make -f - "a b"
echo a b
a b


___

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 #31621] interaction of pattern rules and globs

[Petr Machata]

URL:
  

 Summary: interaction of pattern rules and globs
 Project: make
Submitted by: pmachata
Submitted on: Чтв 11 Ноя 2010 15:39:36
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: CVS
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

make doesn't seem to like pattern rule prerequisites that use globs.  I found
no reference in the manual that states that this should be supported, so I
don't actually know if what I'm asking for is a bug fix or enhancement. 
Anyway:


$ find xxx
xxx
xxx/sums
xxx/sums/zzz.md5
$ make -rd -f x.mk xxx/md5
Reading makefiles...
Reading makefile `x.mk'...
# the following are my two debug printfs
-> parse_file_seq %/md5
-> parse_file_seq %/sums/*.md5
Updating makefiles
<--- snip --->
Updating goal targets
Considering target file `xxx/md5'.
 File `xxx/md5' does not exist.
 Looking for an implicit rule for `xxx/md5'.
 Trying pattern rule with stem `xxx'.
 Trying implicit prerequisite `xxx/sums/*.md5'.
 Trying pattern rule with stem `xxx'.
 Trying implicit prerequisite `xxx/sums/*.md5'.
 Looking for a rule with intermediate file `xxx/sums/*.md5'.
  Avoiding implicit rule recursion.
 No implicit rule found for `xxx/md5'.
 Finished prerequisites of target file `xxx/md5'.
Must remake target `xxx/md5'.
make: *** No rule to make target `xxx/md5'.  Stop.


... the problem being that the wildcard expansion takes place in
read.c:parse_file_seq, when reading the makefile.  That doesn't find any file
matching the %/... path, so it leaves the wild card as is, and later after the
stem-replacement, make looks for xxx/sums/*.md5.




___

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 #31621] interaction of pattern rules and globs

[Petr Machata]

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

Forgot to post this:

$ cat x.mk
%/md5: %/sums/*.md5
echo action


___

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 #31614] allow spaces in target names

[Petr Machata]

2010/11/10 Paul Smith :
> However, this is not nearly the only problem with this suggestion.
> Adding support for whitespace inside filenames is actually extremely
> tricky, because almost all of make is really just text parsing, and all
> that parsing is whitespace-based.

Hmm, right, I didn't realize this.  Functions like sort, word and
others would all need to recognize the escape, wildcard would need to
return escaped spaces... And who knows what that ends up breaking.
I wonder, is the stance that this can of worms is best left closed, or
is that anything that would be desirable?

PM

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

[bug #33873] MAKEFLAGS=-jN gets lost on reexec

[Petr Machata]

URL:
  

 Summary: MAKEFLAGS=-jN gets lost on reexec
 Project: make
Submitted by: pmachata
Submitted on: Срд 27 Июл 2011 22:48:56
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: CVS
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

With CVS and attached Makefile, I'm getting no parallelism:


$ touch foo.c; MAKEFLAGS="-j4" ~/src/make.pm/make
touch Makefile
thing1 start r
thing1 end
thing2 start r
thing2 end


I tracked the problem down to the commit from 2009-06-09 17:36. The cause
seems to be that when make is about to re-exec, it calls define_makeflags. 
But at that time, the value of job_slots is 1 due to call to clean_jobserver
around make.c:2046, and thus -j from MAKEFLAGS is tossed.

But even if it weren't, there's a special check in define_makeflags that
disregards this value.  I thought that that's to prevent launching multiple
sub-makes, but that isn't what happens when I comment the code out.  Perhaps
it's only relevant when MAKE_JOBSERVER is not defined?  In my patch, I have it
ifdefed out in a straightforward manner, but most probably that's not the
right thing to do (although no test cases break...).



___

File Attachments:


---
Date: Срд 27 Июл 2011 22:48:56  Name: makeflags.patch  Size: 1kB   By:
pmachata


---
Date: Срд 27 Июл 2011 22:48:56  Name: Makefile  Size: 132B   By:
pmachata



___

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 #39851] Stack limit not restored for processes spawned through $(shell)

[Petr Machata]

URL:
  

 Summary: Stack limit not restored for processes spawned
through $(shell)
 Project: make
Submitted by: pmachata
Submitted on: Чтв 22 Авг 2013 14:54:01
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

This is complementary to a fix e8ca9b8e from 16 Feb 2005.  That restores stack
limit for processes launched for targets, but omits to also restore it for
processes launched through $(shell) expansion.  The attached patch
straightforwardly expands the fix to that situation as well.



___

File Attachments:


---
Date: Чтв 22 Авг 2013 14:54:01  Name:
0001-Get-rid-of-stack-size-limit-for-processes-spawned-vi.patch  Size: 1kB  
By: pmachata
A fix


___

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 #39851] Stack limit not restored for processes spawned through $(shell)

[Petr Machata]

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

Hmm, this breaks targets/SECONDARY.

___

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 #39851] Stack limit not restored for processes spawned through $(shell)

[Petr Machata]

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

Scratch that, that seems to be interaction between this and other downstream
patches.  The upstream test suite consistently passes.

___

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 #39851] Stack limit not restored for processes spawned through $(shell)

[Petr Machata]

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

OK, the test is racy.  I see it was fixed in 3057357c from 10 Dec 2011.

___

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 #39934] make closes a wrong FD, results in *** INTERNAL: readdir: Bad file descriptor

[Petr Machata]

URL:
  <http://savannah.gnu.org/bugs/?39934>

 Summary: make closes a wrong FD, results in *** INTERNAL:
readdir: Bad file descriptor
 Project: make
Submitted by: pmachata
Submitted on: Втр 03 Сен 2013 17:44:02
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

This was filed in Red Hat bugzilla here:
https://bugzilla.redhat.com/show_bug.cgi?id=885474

To reproduce this, use the following Makefile:
default:
/home/petr/src/make/build/make -f Makefile2

And the following Makefile2 (note: the path in vpath must exist):
vpath %.c/home/petr/
foo:

Then run make:
$ make -j 2
/home/petr/src/make/build/make -f Makefile2
make[1]: Entering directory `/home/petr/tmp/tst'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make
rule.
make[1]: *** INTERNAL: readdir: Bad file descriptor
.  Stop.
make[1]: Makefile2: Field 'stem' not cached: Makefile2

make[1]: Leaving directory `/home/petr/tmp/tst'
make: *** [default] Error 2

The following excerpt from an ltrace run illustrates the problem:
18706 16:46:43.945567 opendir("/home/petr" 
18706 16:46:43.945713 SYS_open("/home/petr", 591872, 0172204710) = 4
18706 16:46:43.945785 SYS_brk(0) = 0x1e9d000
18706 16:46:43.945824 SYS_brk(0x1ec5000) = 0x1ec5000
18706 16:46:43.945870 <... opendir resumed> )= { 4 }
[...]
18706 16:46:44.34 close(4 
18706 16:46:44.347882 SYS_close(4)   = 0
18706 16:46:44.347927 <... close resumed> )  = 0
[...]
18706 16:46:45.718922 readdir({ 4 } 
18706 16:46:45.719037 SYS_getdents(4, 0x161f008, 32768)  = -9
18706 16:46:45.719103 <... readdir resumed> )= 0

The problem arises when parental make passes down jobserver FDs in the
environment, but the child make is not run as part of this jobsever batch. 
Child make notices JOB_FDS numbers passed down, and tries to dup, which fails,
because JOB_FDS[0] is invalid.  In then switches to -j1, and proceeds to close
JOB_FDS.  But in the meantime make managed to reuse one of those descriptors
for a directory stream for vpath.  When that is closed it later causes the
error message seen in the subject.

The immediate idea is not to close JOB_FDS if the dup fails.  That's certainly
part of the solution (because otherwise we end up calling close over invalid
file descriptors).  But that it fails is pure luck: make gets FD 3 for
Makefile2, then FD 4 for vpath dirstream, and then closes 3 after it's done
with it.  Had --jobserver-fds been 4 and 5, we would dup it without trouble.

But perhaps it's possible to move read_all_makefiles down beyond the JOB_FDS
business.  Then there would be no file operations except those in the dynamic
linker, and those don't leak descriptors.  Then we can use the dup as a
reliable test.  However I don't know whether there are interactions that I
don't see, and whether it's safe and desirable to postpone the parsing to a
later time like this.  The test suite passes with this FWIW.



___

File Attachments:


---
Date: Втр 03 Сен 2013 17:44:02  Name:
0001-Don-t-close-JOB_FDS-if-we-know-they-are-invalid.patch  Size: 2kB   By:
pmachata
A fix
<http://savannah.gnu.org/bugs/download.php?file_id=28997>

___

Reply to this item at:

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

___
  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 #39934] make closes a wrong FD, results in *** INTERNAL: readdir: Bad file descriptor

[Petr Machata]

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

This is consistently reproducible with current git HEAD (40a49f24) as well as
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

I miss a parametr to rebuild all...

[Petr Slansky]

Hello,

I miss a parametr to rebuild whole project. I used Borland make in the past
and that one had "-B" command line option to don't test timemarks and rebuild
all. I miss it in GNU make. I found there is "-W file" option but this is not
simple. Sometimes I just need to rebuild all, not all Makefiles in the world
are done in well way... I miss an option to don't check timemarks of files and
rebuild. With combination of "-n" I will see project creation process...

Thanks for your help,
Petr



=
  Petr Slansky, [EMAIL PROTECTED]
=



Get free email and a permanent address at http://www.netaddress.com/?N=1

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

cygwin make 3.79.1 crashes

[Petr Balas]

I'm trying to build AbiWord for Windows. make crashes:

make.exe.stackdump:
Exception: STATUS_ACCESS_VIOLATION at eip=0040D5EF
eax=0004 ebx=614E6A44 ecx=61098838 edx=0242EE98 esi=
edi=
ebp=0242EED4 esp=0242EEA4 program=U:\CygWin\bin\make.exe
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function  Args
0242EED4  0040D5EF  (0007, 0A017530, 00C8, 00408BAE)
0242EEF4  61082652  (0007, 0A017530, 00C8, 00408BDE)
0242EF84  00408BFB  (0A017710, 0242EFCC, 00408D8E, 00400022)
0242EFB4  00408F25  (0A017710, 0001, 0242EFCC, 004260B4)
0242F014  00409149  (0242F07C, 0242F080, , 00403F3D)
0242F094  00403FFA  (, 0A015BD6, , 00404636)
0242F0B4  004045AA  (0A015BD6, 0007, 0242F104, 0041DAA8)
0242F0E4  00404636  (0A015BD6, , 0242F134, 6108061C)
0242F114  004048A2  (0A015BD6, , 000A, 0041EA1C)
0242F174  0041EB0F  (0242F24C, 0A015BC8, 0002, )
0242F264  00414EFD  (0A016F50, 000A, 0007, )
0242F354  00414E5C  (0A015E10, 000A, 0007, )
0242F444  00414E5C  (004139CA, , 0242F494, 004212D1)
0242F494  00413BA2  (, , 0242FEB4, 0041046B)
0242FEB4  004104A7  (0005, 614E50AC, 0A010008, )
0242FF10  6100401E  (, 0022F666, 8200, 0200)
End of stack trace (more stack frames may be present)


$ make -v
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-cygwin
...

System:
Windows 2000 SP2

If you need more informations contact me.

Petr Balas (petr at balas dot cz)


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

make 3.80: -B option is not documented in man and info pages

[Petr Slansky]

make 3.80:
Thanks for -B option very much, it seems to work well. 
-B option is not documented in man and info pages.
There is an alterntaive --always-make for -B option, from my point of view, 
--rebuild-all will be better but I am happy with --alwayes-make too.

With regards,
Petr



-
  Petr Slansky, [EMAIL PROTECTED]
-



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