[bug #16132] Quoting problem in 3.81rc1
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16132 Summary: Quoting problem in 3.81rc1 Project: make Submitted by: None Submitted on: Mon 03/20/06 at 12:12 Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Component Version: None Platform Version: MS Windows Fixed Release: None ___ Details: # GNU Make 3.80 gives: # -aap=noot # -aap=noot # -aap=noot # -aap=noot -mies=wim # -aap=noot -mies=wim # -aap=noot -mies=wim # # GNU Make 3.81 b3 gives: # -aap=noot # -aap=noot # -aap=noot # -aap=noot -mies=wim # -aap=noot -mies=wim # -aap=noot -mies=wim # # # GNU Make 3.81 rc1 gives: # -aap=noot # -aap=\noot # -aap=\noot # -aap=noot -mies=wim # -aap=noot -mies=wim # -aap=\noot -mies=wim # BLA1 := -aap=noot BLA2 := '-aap=noot' BLA3 := -aap=\noot\ BLA4 := -aap=noot -mies=wim BLA5 := '-aap=noot -mies=wim' BLA6 := -aap=\noot\ -mies=\wim\ all: @echo $(BLA1) @echo $(BLA2) @echo $(BLA3) @echo $(BLA4) @echo $(BLA5) @echo $(BLA6) ___ File Attachments: --- Date: Mon 03/20/06 at 12:12 Name: makefile2 Size: 764B By: None example makefile (see submission) http://savannah.gnu.org/bugs/download.php?item_id=16132item_file_id=3508 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16132 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16132] Quoting problem in 3.81rc1
Update of bug #16132 (project make): Status:None = Works for me ___ Follow-up Comment #1: I can't reproduce this on GNU/Linux; both rc1 and the latest CVS code work fine. Please provide more details about your OS: what version of Windows; which shell are you using; etc. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16132 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
GNU make 3.81rc2 has been released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all; Please find GNU make 3.81rc2, available now for download from ftp://alpha.gnu.org/gnu/make: ecebd3e477587603cd074183fbf7a302 ftp://alpha.gnu.org/gnu/make/make-3.81rc2.tar.gz 4dc9dc889366f0e297ee5127bc6cd930 ftp://alpha.gnu.org/gnu/make/make-3.81rc2.tar.bz2 A number of bugs and problems were fixed. In particular, a bug fix which caused the Linux kernel build system to behave improperly has been deferred until the next release. This is a release candidate; unless important errors are discovered the official release will be made sometime next week. Please make every effort to test this release on as many systems and in as many situations as possible. Have fun! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEHq89lrBHFWM4ttQRAgPVAJwOSELewoWUQ6U/lI596JkNPq4/bACdGdLQ ylhbhattSsqIymPTAd7GsiI= =n5jQ -END PGP SIGNATURE- -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16118] Change of behavior in beta[34] for -include
Update of bug #16118 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #1: As best as I can tell this change was made intentionally. The GNU make manual says: If you want `make' to simply ignore a makefile which does not exist and cannot be remade, with no error message, use the `-include' directive instead of `include' The behavior of the previous versions of make did not match this description, since make would fail if it could not remake an included makefile. If you want make to fail when a makefile can't be rebuilt, then you should use include instead of -include. A few other points: be careful to write your .d creation script so that if the .c file does not exist it will either fail or at least it won't create an empty .d file. If you use -include then make will ignore it when it fails but at least you won't incorrectly hide the problem. I suppose another option is to generate a .d file with a syntax error in it, then when make re-execs it will fail. But this is a problem because you'll have to delete the broken .d file by hand before make will work again. Also, one would assume that the non-existent .c file would cause a failure of some kind during the normal build portion of the makefile (not building .d files) so I don't see how this kind of error can go unnoticed for long. I'm closing this as Not a Bug for now; please feel free to add more information about your situation and we can continue to discuss it. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16118 ___ 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 in 3.8.0
define build_proj_template $(1): $(foreach bb,$(BB_$(patsubst build+%,%,$(1))),$(addsuffix +$(bb),$(addprefix build+,$(patsubst build+%,%,$(1) @echo build_proj_template $(1) endef $(foreach proj,$(PROJECTS),$(eval $(call build_proj_template,$(addprefix build+,$(proj) If I change the eval to warning 3.79ok 3.79.1 ok 3.8.0 ok 3.8.1 ok change warning back to eval 3.79nothing 3.79.1 nothing 3.8.0 segmentation fault core dump 3.8.1 ok Since 3.8.1 is beta. It cannot put it to a production environment. I'm between a rock and a hard place. 3.79 is installed but doesn't work. The impact is taking a hard look at upgrading some of the servers to 3.8.0. but it failes. 3.8.1 isn't released yet. Segmentation fault (core dumped) (gdb) bt #0 0xc0199cbc in _sigfillset+0x26fc () from /usr/lib/libc.2 #1 0xc0197e18 in _sigfillset+0x858 () from /usr/lib/libc.2 #2 0xc0198cfc in _sigfillset+0x173c () from /usr/lib/libc.2 #3 0xc0195bec in _sscanf+0x8fc () from /usr/lib/libc.2 #4 0xc019b510 in realloc+0x1a0 () from /usr/lib/libc.2 #5 0x1f738 in xrealloc ( ptr=0x40018f78 build+ldb : build+ldb+inftp build+ldb+opi build+ldb+schapi build+ldb+tuxapi build+ldb+ldngn build+ldb+in fgn build+ldb+ldgn build+ldb+ld Address 0x40019000 out of bounds, size=4294965501) at misc.c:384 #6 0xb5ec in variable_buffer_output (ptr=0x40018810 @[EMAIL PROTECTED], string=0x40018498 , length=1) at expand.c:67 #7 0xba08 in variable_expand_string (line=0x40018810 @[EMAIL PROTECTED], string=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj, length=-1) at expand.c:207 #8 0xc0e4 in variable_expand (line=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj) at expand.c:415 #9 0xc224 in variable_expand_for_file ( line=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj, file=0x0) at expand.c:457 #10 0xc510 in allocated_variable_expand_for_file ( line=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj, file=0x0) at expand.c:555 #11 0x11478 in func_foreach (o=0x40017bf8 build_proj_template, argv=0x68ff1870, funcname=0x36a98 foreach) at function.c:874 #12 0x12c80 in expand_builtin_function (o=0x40017bf8 build_proj_template, argc=3, argv=0x68ff1870, entry_p=0x40003604) at function.c:1864 #13 0x12fd8 in handle_function (op=0x68ff17a4, stringp=0x68ff17a8) at function.c:1964 #14 0xbac8 in variable_expand_string (line=0x40017bf8 build_proj_template, string=0x40017390 $(foreach proj,$(PROJECTS),$(eval $(call build_proj_template,$(addprefix build+,$(proj), length= 91) at expand.c:235 #15 0x21c38 in eval (ebuf=0x68ff1574, set_default=1) at read.c:913 #16 0x20828 in eval_makefile (filename=0x40015148 XXX, flags=0) at read.c:379 #17 0x201a8 in read_all_makefiles (makefiles=0x4000fe70) at read.c:205 #18 0x1b390 in main (argc=3, argv=0x68ff0694, envp=0x68ff06a4) at main.c:1444 (gdb) XXX Description: XXX ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: bug in 3.8.0
I'm between a rock and a hard place. I know - I'm in a similar position. Having code which reliably generates rules (with $eval) is a powerful feature and, once you've tasted it, it's hard to give it up. However, I've been using the 3.81 beta builds very successfully on a number of platforms for many months. Debian's testing distribution has had 3.81 beta builds for a couple of months now. It's good to go, or very nearly so. 3.8.1 isn't released yet. Not for long. Paul's making a serious effort to get 3.81 released - the hope is it will be this very week. make-3.81rc2 is now available from ftp://alpha.gnu.org/gnu/make (in case you're still using a beta build). The previous (3.80) release of make was about three and a half years ago. Hopefully 3.82 won't take as long but, if 3.81rc2 exhibits any problems in your production environment, now would be a really, really good time to report them. - Martin's Outlook, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of PATTON, BILLY (SBCSI) Sent: Friday, March 17, 2006 4:53 To: bug-make@gnu.org Subject: bug in 3.8.0 define build_proj_template $(1): $(foreach bb,$(BB_$(patsubst build+%,%,$(1))),$(addsuffix +$(bb),$(addprefix build+,$(patsubst build+%,%,$(1) @echo build_proj_template $(1) endef $(foreach proj,$(PROJECTS),$(eval $(call build_proj_template,$(addprefix build+,$(proj) If I change the eval to warning 3.79ok 3.79.1 ok 3.8.0 ok 3.8.1 ok change warning back to eval 3.79nothing 3.79.1 nothing 3.8.0 segmentation fault core dump 3.8.1 ok Since 3.8.1 is beta. It cannot put it to a production environment. I'm between a rock and a hard place. 3.79 is installed but doesn't work. The impact is taking a hard look at upgrading some of the servers to 3.8.0. but it failes. 3.8.1 isn't released yet. Segmentation fault (core dumped) (gdb) bt #0 0xc0199cbc in _sigfillset+0x26fc () from /usr/lib/libc.2 #1 0xc0197e18 in _sigfillset+0x858 () from /usr/lib/libc.2 #2 0xc0198cfc in _sigfillset+0x173c () from /usr/lib/libc.2 #3 0xc0195bec in _sscanf+0x8fc () from /usr/lib/libc.2 #4 0xc019b510 in realloc+0x1a0 () from /usr/lib/libc.2 #5 0x1f738 in xrealloc ( ptr=0x40018f78 build+ldb : build+ldb+inftp build+ldb+opi build+ldb+schapi build+ldb+tuxapi build+ldb+ldngn build+ldb+in fgn build+ldb+ldgn build+ldb+ld Address 0x40019000 out of bounds, size=4294965501) at misc.c:384 #6 0xb5ec in variable_buffer_output (ptr=0x40018810 @[EMAIL PROTECTED], string=0x40018498 , length=1) at expand.c:67 #7 0xba08 in variable_expand_string (line=0x40018810 @[EMAIL PROTECTED], string=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj, length=-1) at expand.c:207 #8 0xc0e4 in variable_expand (line=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj) at expand.c:415 #9 0xc224 in variable_expand_for_file ( line=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj, file=0x0) at expand.c:457 #10 0xc510 in allocated_variable_expand_for_file ( line=0x40018459 $(eval $(call build_proj_template,$(addprefix build+,$(proj, file=0x0) at expand.c:555 #11 0x11478 in func_foreach (o=0x40017bf8 build_proj_template, argv=0x68ff1870, funcname=0x36a98 foreach) at function.c:874 #12 0x12c80 in expand_builtin_function (o=0x40017bf8 build_proj_template, argc=3, argv=0x68ff1870, entry_p=0x40003604) at function.c:1864 #13 0x12fd8 in handle_function (op=0x68ff17a4, stringp=0x68ff17a8) at function.c:1964 #14 0xbac8 in variable_expand_string (line=0x40017bf8 build_proj_template, string=0x40017390 $(foreach proj,$(PROJECTS),$(eval $(call build_proj_template,$(addprefix build+,$(proj), length= 91) at expand.c:235 #15 0x21c38 in eval (ebuf=0x68ff1574, set_default=1) at read.c:913 #16 0x20828 in eval_makefile (filename=0x40015148 XXX, flags=0) at read.c:379 #17 0x201a8 in read_all_makefiles (makefiles=0x4000fe70) at read.c:205 #18 0x1b390 in main (argc=3, argv=0x68ff0694, envp=0x68ff06a4) at main.c:1444 (gdb) ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16132] Quoting problem in 3.81rc1
Follow-up Comment #2, bug #16132 (project make): I cannot reproduce this, either, on Windows XP. I tried with and without a Unixy sh.exe on my PATH, and both behave as expected, identically to v3.80 and v3.80b4. (The behavior with and without sh.exe is not identical, but that's because the `echo' built-in behaves differently in each case, as far as removing single and double quotes is concerned.) What kind of sh.exe are you using, and how (with what compiler and development environment) did you build Make 3.81rc1? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16132 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16138] multiple jobservers started up by parallel make (and so uses 4 FDs instead of just 2)
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16138 Summary: multiple jobservers started up by parallel make (and so uses 4 FDs instead of just 2) Project: make Submitted by: None Submitted on: Mon 03/20/06 at 21:58 Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Component Version: 3.79.1 Platform Version: POSIX-Based Fixed Release: None ___ Details: The command 'make test' with the following makefile fails when trying to process the 'submake' target in the 2nd makefile (makefile2) because file descriptor 5 is being used by the parallel make jobserver. If you then do another 'make test', it works because 'dependfile' exists. It seems that when make is making the 'dependfile' so it can do the 'include dependfile' it starts up a jobserver (using FD 3,4) and then when it processes the 'submake' target, it does not know about the first jobserver and so starts up another jobserver (using FD 5,6). Running on a Linux machine where uname -a returns: Linux lnxmach1 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux makefile test: @echo MAKE=$(MAKE) MAKEFLAGS=$(MAKEFLAGS)MFLAGS=$(MFLAGS) $(MAKE) -f makefile2 -j 2 submake makefile2 - dependfile: @echo SOMEMACRO=joe $@ @echo MAKE=$(MAKE) MAKEFLAGS=$(MAKEFLAGS)MFLAGS=$(MFLAGS) include dependfile submake: @echo MAKE=$(MAKE) MAKEFLAGS=$(MAKEFLAGS)MFLAGS=$(MFLAGS) $(MAKE) -f makefile2 fdprint 5output fdprint: @echo MAKE=$(MAKE) MAKEFLAGS=$(MAKEFLAGS)MFLAGS=$(MFLAGS) @echo hi 5 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16138 ___ 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 #16138] multiple jobservers started up by parallel make (and so uses 4 FDs instead of just 2)
Update of bug #16138 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:None = CVS ___ Follow-up Comment #1: I fixed this in CVS; the fix is available in the latest release candidate: ftp://alpha.gnu.org/gnu/make/make-3.81rc2.tar.bz2 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16138 ___ 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
