Bug report
Hi, i cant install most of the packages, "make" doesnt work "no C compilers". Im jus a beginner Linux user, please help, i wanna install VPN cisco client, which im unable to do to access inet. cheers abhishek - You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Bug report
Hello I downloaded the JunkyardJumbotron app. I am not able to run the project for iOS. I am getting this error. "cp: /javascripts/phonegap.js: No such file or directory". Also, it is written there to contact "bug-make@gnu.org". I have installed PhoneGap and Cordova.I hope for your response. Thanks and regards. -- Rajan Kambaliya iOS Developer Skype: rajan.kambaliya22 www.multidots.com ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
bug report
I wrote a makefile with $(BUILD)/$(FRONTEND)/%.html \ $(BUILD)/$(FRONTEND)/%.js \ $(BUILD)/$(FRONTEND)/%.css \ $(BUILD)/$(FRONTEND)/%.svg \ $(BUILD)/$(FRONTEND)/%.ico: @echo -n "$(FRONTEND) - building $@" @$(MD) $(BUILD)/$(FRONTEND) @cp $(FRONTEND)/$(@F) $@ @echo " ...done" .PHONY: login: $(BUILD)/$(FRONTEND)/login.html \ $(BUILD)/$(FRONTEND)/login.js $(BUILD)/$(FRONTEND)/options.js $(BUILD)/$(FRONTEND)/node.js \ $(BUILD)/$(FRONTEND)/login.css $(BUILD)/$(FRONTEND)/common.css \ $(BUILD)/$(FRONTEND)/logo.svg \ $(BUILD)/$(FRONTEND)/favicon.ico @echo -n "$(FRONTEND) - building login" @echo " ...done" I get no errors but only if I repeat the command 3 times (3 files with same prefix) I got the result. q@odysseus:~/ff$ make login frontend - building build/frontend/login.html ...done frontend - building build/frontend/options.js ...done frontend - building build/frontend/node.js ...done frontend - building build/frontend/common.css ...done frontend - building build/frontend/logo.svg ...done frontend - building build/frontend/favicon.ico ...done frontend - building login ...done q@odysseus:~/ff$ make login frontend - building build/frontend/login.js ...done frontend - building login ...done q@odysseus:~/ff$ make login frontend - building build/frontend/login.css ...done frontend - building login ...done With help and instructions from ##workingsets I got further to make -k -d login Successfully remade target file `build/foo/login.html'. Considering target file `build/foo/login.js'. File `build/foo/login.js' was considered already. but `build/foo/login.js' was NOT considered already. Any hints? Is this a feature or a bug? Thanks Goran
bug report
I'm sorry this isn't in the proper bug reporting format, but time is pretty critical right now on our project. In any case, we ran into a subtle bug that was partially caused by our environment and how we've used gnumake, but I figured that since its such a pain in the ass, you guys may want to know about it. The problem is only occurring on a Windows 2000 system. To give some background, we've written a sort of macro language that created GNUMakefiles automatically to make it easier for developers to write the makefiles. In some cases developers were exporting environment variables that were devoid of a value. So in other words, when arr2envblk() in misc.c started to accumulate them into a block of memory for process_begin() in sub_proc.c, some would be added in the form: foo= bar= baz= Apparently CreateProcess really dislikes this because it would give a most unpleasant error, returning an ERROR_MORE_DATA from GetLastError. Although this makes sense now, the fact that it is undocumented caused weeks of pain for us. My solution was to check for variables with no value and not include them in the environment block and the problem went away. I hope this helps. Keep up the good work. Fran Francis Grolemund Edge Server Development IBM Pittsburgh Lab (412) 667-4989 T/L: 989-4989 [EMAIL PROTECTED] ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
bug report
Duh. I almost forgot. We're using version 3.78.1 of GNUMake. Francis Grolemund Edge Server Development IBM Pittsburgh Lab (412) 667-4989 T/L: 989-4989 [EMAIL PROTECTED] -- Forwarded by Francis Grolemund/Pittsburgh/IBM on 07/16/2001 09:52 PM --- Francis Grolemund 07/16/2001 09:47 PM To: [EMAIL PROTECTED] cc: From: Francis Grolemund/Pittsburgh/IBM@IBMUS Subject: bug report I'm sorry this isn't in the proper bug reporting format, but time is pretty critical right now on our project. In any case, we ran into a subtle bug that was partially caused by our environment and how we've used gnumake, but I figured that since its such a pain in the ass, you guys may want to know about it. The problem is only occurring on a Windows 2000 system. To give some background, we've written a sort of macro language that created GNUMakefiles automatically to make it easier for developers to write the makefiles. In some cases developers were exporting environment variables that were devoid of a value. So in other words, when arr2envblk() in misc.c started to accumulate them into a block of memory for process_begin() in sub_proc.c, some would be added in the form: foo= bar= baz= Apparently CreateProcess really dislikes this because it would give a most unpleasant error, returning an ERROR_MORE_DATA from GetLastError. Although this makes sense now, the fact that it is undocumented caused weeks of pain for us. My solution was to check for variables with no value and not include them in the environment block and the problem went away. I hope this helps. Keep up the good work. Fran Francis Grolemund Edge Server Development IBM Pittsburgh Lab (412) 667-4989 T/L: 989-4989 [EMAIL PROTECTED] ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Bug report
Hi, there is a problem with make I cannot figure out at all. Hence I send you the make-file causing the headaches. I am more than happy to supply further information or give you access to my machine to do further tests. Best regards, W. Doeringer PS.: Otherwise, I have been using make for years and it did not fail! # PLEASE NOTE THE LINES FOLLOWING "COMMENT" # + # (c) AG ProgrammbauFH Worms[EMAIL PROTECTED] + # + # HTTP Server in C++ + # + # Datei: HTTP/Server/C++/Code/Nachrichten/XDebug.mk # AutorIn: w.doeringer(@acm.org) # Beschreibung: Make Datei fuer die Nachrichten-Bibliothek # System: GNU - Linux [, Solaris] # Revision: 2002/12/16 # - # # --- Die Variable MakePStd muss auf das allgemeine Make-Verzeichnis zeigen --- include $(MakePStd)/C++/XDbgCpp.Inc # Projekt-spezifische Definitionen include ../../Make/XDbgCppProj.Inc # # Compiler Optionen # # --- Die generische Pseudo-Zieldatei - all:$(LibP)/NachrichtenDbg.a \ tCdaten \ tCn \ tCnDELETE\ tCnGET \ tCscanner\ tCscannerIn \ tNamen # # --- Die Bibliothek - # $(LibP)/NachrichtenDbg.a : \ NachrichtenDbg.a cp NachrichtenDbg.a $(LibP) # NachrichtenDbg.a: \ Cscanner.o \ Cdaten.o \ Cn.o \ CnDELETE.o \ CnGET.o \ Namen.o \ $(MakeP)/XDbgCppProj.Inc \ $(MakePStd)/C++/XDbgCpp.Inc $(LibrAriaN) $(LibOpt) $*.a Cscanner.o Cdaten.o Cn.o \ CnDELETE.o CnGET.o \ Namen.o # # --- Der Scanner $(QuellP)/Cscanner.h: \ $(BasisP)/CLog.h \ $(ZeileP)/Csymbol.h $(TouCH) $@ # Cscanner.o: \ $(BasisP)/Proj.h \ $(BasisP)/CLog.h \ $(QuellP)/Cscanner.h \ $(QuellP)/Cscanner.cpp \ $(MakeP)/XDbgCppProj.Inc \ $(MakePStd)/C++/XDbgCpp.Inc $(ComPileR) $(CompOpt) $(QuellP)/$*.cpp # # --- Cdaten $(QuellP)/Cdaten.h: \ $(BasisP)/CLog.h $(TouCH) $@ Cdaten.o: \ $(BasisP)/Proj.h \ $(BasisP)/CLog.h \ $(ConfiP)/Cconfig.h\ $(KonstP)/StatusCodes.h\ $(QuellP)/Cdaten.h \ $(QuellP)/Cdaten.cpp \ $(MakeP)/XDbgCppProj.Inc \ $(MakePStd)/C++/XDbgCpp.Inc $(ComPileR) $(CompOpt) $(QuellP)/$*.cpp # # --- Die Cnxxx $(QuellP)/Cn.h: \ $(QuellP)/ChttpNachricht.h $(TouCH) $@ # Cn.o: \ $(BasisP)/Proj.h \ $(BasisP)/CLog.h \ $(KonstP)/StatusCodes.h\ $(ZeileP)/CZrspLine.h \ $(ZeileP)/CZserver.h \ $(QuellP)/Cn.h \ $(QuellP)/CnGET.h \ $(QuellP)/Cn.cpp \ $(MakeP)/XDbgCppProj.Inc \ $(MakePStd)/C++/XDbgCpp.Inc $(ComPileR) $(CompOpt) $(QuellP)/$*.cpp # $(QuellP)/CnDELETE.h: \ $(ZeileP)/CZconnection.h \ $(ZeileP)/CZcontLocation.h\ $(ZeileP)/CZcontType.h\ $(ZeileP)/CZdate.h\ $(ZeileP)/CZhostPort.h\ $(ZeileP)/CZIfModifiedSince.h \ $(ZeileP)/CZnull.h\ $(ZeileP)/CZreqLine.h \ $(ZeileP)/CZrspLine.h \ $(QuellP)/Cscanner.h $(TouCH) $@ # CnDELETE.o: \ $(BasisP)/Proj.h \ $(BasisP)/CLog.h \ $(BasisP)/cctypeProj.h\ $(KonstP)/Codes.h \ $(KonstP)/StatusCodes.h \ $(ConfiP)/Cconfig.h \ $(ZeileP)/Csymbol.h \ $(QuellP)/CnDELETE.h \ $(QuellP)/CnDELETE.cpp\ $(MakeP)/XDbgCppProj.Inc \
bug report
In one of my makefile, I have following conditional syntax: ADDONS_DB_C = $(EXCLUDEFWKLIB?:$(TMP_ADDONS_DB_C)) This gives me an error for MACRO SUBSTITUTION Thanks, Sandeep Nema ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: bug report
On Wed, 2021-03-03 at 17:31 +0100, Goran V. wrote: > $(BUILD)/$(FRONTEND)/%.html \ > $(BUILD)/$(FRONTEND)/%.js \ > $(BUILD)/$(FRONTEND)/%.css \ > $(BUILD)/$(FRONTEND)/%.svg \ > $(BUILD)/$(FRONTEND)/%.ico: > @echo -n "$(FRONTEND) - building $@" > @$(MD) $(BUILD)/$(FRONTEND) > @cp $(FRONTEND)/$(@F) $@ > @echo " ...done" I think you're misunderstanding what a pattern rule with multiple targets means to GNU make. See: https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.html (last paragraph). It means that one invocation of the recipe will create ALL the targets. That's why make believes it's already considered all the other targets that are listed as patterns here, even though it only ran the recipe one time. Note this is the opposite of what an explicit rule with multiple targets means: that defines multiple unique rules, one for each target.
Re: bug report
Maybe I was wrong to call this a bug but would a feature like that break anything? Am Mittwoch, den 03.03.2021, 13:55 -0500 schrieb Paul Smith: > On Wed, 2021-03-03 at 17:31 +0100, Goran V. wrote: > > $(BUILD)/$(FRONTEND)/%.html \ > > $(BUILD)/$(FRONTEND)/%.js \ > > $(BUILD)/$(FRONTEND)/%.css \ > > $(BUILD)/$(FRONTEND)/%.svg \ > > $(BUILD)/$(FRONTEND)/%.ico: > > @echo -n "$(FRONTEND) - building $@" > > @$(MD) $(BUILD)/$(FRONTEND) > > @cp $(FRONTEND)/$(@F) $@ > > @echo " ...done" > > I think you're misunderstanding what a pattern rule with multiple > targets means to GNU make. > > See: > https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.html > (last paragraph). > > It means that one invocation of the recipe will create ALL the > targets. > That's why make believes it's already considered all the other > targets > that are listed as patterns here, even though it only ran the recipe > one time. > > Note this is the opposite of what an explicit rule with multiple > targets means: that defines multiple unique rules, one for each > target. >
Re: bug report
On Wed, 2021-03-03 at 21:32 +0100, Goran V. wrote: > Maybe I was wrong to call this a bug but would a feature like that > break anything? If by "a feature like that" you mean a way to create multiple pattern rules with a single rule definition in the makefile, then obviously this would require some new syntax but assuming that syntax existed I don't see why it would break anything.
Re: bug report
Am Mittwoch, den 03.03.2021, 15:41 -0500 schrieb Paul Smith: > If by "a feature like that" you mean a way to create multiple pattern > rules with a single rule definition in the makefile, then obviously > this would require some new syntax but assuming that syntax existed I > don't see why it would break anything. Yes, that is what I mean with "a feature like that". But I must say that I'm in no position to propose a patch as make is huge, http://git.savannah.gnu.org/cgit/make.git/tree/ . I can only ask you to add that feature if you see any benefit in it?
Re: bug report
On Wed, 2021-03-03 at 22:00 +0100, Goran V. wrote: > Am Mittwoch, den 03.03.2021, 15:41 -0500 schrieb Paul Smith: > Yes, that is what I mean with "a feature like that". But I must say > that I'm in no position to propose a patch as make is huge, > http://git.savannah.gnu.org/cgit/make.git/tree/ . Heh. I think make is a pretty modestly-sized program. I guess it's all what you're used to :). > I can only ask you to add that feature if you see any benefit in it? If you'd like to propose an enhancement the best way to do it is here: https://savannah.gnu.org/bugs/?group=make&func=additem Cheers!
Re: bug report
On Wed, Mar 3, 2021 at 1:00 PM Goran V. wrote:
> Am Mittwoch, den 03.03.2021, 15:41 -0500 schrieb Paul Smith:
> > If by "a feature like that" you mean a way to create multiple pattern
> > rules with a single rule definition in the makefile, then obviously
> > this would require some new syntax but assuming that syntax existed I
> > don't see why it would break anything.
>
> Yes, that is what I mean with "a feature like that". But I must say
> that I'm in no position to propose a patch as make is huge,
> http://git.savannah.gnu.org/cgit/make.git/tree/ .
>
This can be emulated in current GNU make via a function and a variable to
hold the commands.
To get the effect you wanted, you would define this function in one place,
before any use of it:
independent_patterns = $(foreach target, $1, $(eval ${target}: ${2};
$(value $(strip $3
Then, instead of writing what you tried:
$(BUILD)/$(FRONTEND)/%.html \
$(BUILD)/$(FRONTEND)/%.js \
$(BUILD)/$(FRONTEND)/%.css \
$(BUILD)/$(FRONTEND)/%.svg \
$(BUILD)/$(FRONTEND)/%.ico:
@echo -n "$(FRONTEND) - building $@"
@$(MD) $(BUILD)/$(FRONTEND)
@cp $(FRONTEND)/$(@F) $@
@echo " ...done"
You would write this:
define cmds
@echo -n "$(FRONTEND) - building $@"
@$(MD) $(BUILD)/$(FRONTEND)
@cp $(FRONTEND)/$(@F) $@
@echo " ...done"
endef
$(call independent_patterns, \
$(BUILD)/$(FRONTEND)/%.html \
$(BUILD)/$(FRONTEND)/%.js \
$(BUILD)/$(FRONTEND)/%.css \
$(BUILD)/$(FRONTEND)/%.svg \
$(BUILD)/$(FRONTEND)/%.ico, , cmds)
Not the most obvious, friendly syntax, but it appears to do what you're
trying to accomplish.
Philip Guenther
Re: Bug Report
On Sat, 2022-09-10 at 23:12 +0300, Fosil Crypto wrote: > ubuntu@ip-172-31-95-154:~$ make ncdu gcc git jq chrony liblz4-tool -y > make: invalid option -- 'y' This is not a bug. You are just invoking make incorrectly.
Re: bug report
%% Francis Grolemund <[EMAIL PROTECTED]> writes: fg> In any case, we ran into a subtle bug that was partially caused by fg> our environment and how we've used gnumake, but I figured that fg> since its such a pain in the ass, you guys may want to know about fg> it. The problem is only occurring on a Windows 2000 system. To fg> give some background, we've written a sort of macro language that fg> created GNUMakefiles automatically to make it easier for fg> developers to write the makefiles. In some cases developers were fg> exporting environment variables that were devoid of a value. So fg> in other words, when arr2envblk() in misc.c started to accumulate fg> them into a block of memory for process_begin() in sub_proc.c, fg> some would be added in the form: fg> foo= fg> bar= fg> baz= You're saying, they had the literal string "" in the value? Did these strings appear in the makefile you generated? If so, this sounds to me like a bug in your macro language. Many C runtime implementations of printf(), fprintf(), etc. try to be "helpful" and if you give a NULL pointer to them where a %s should go, they print the constant string "". In that case you should check for the NULL pointer and handle it, something like: fprintf(fp, "%s=%s\n", variable, value ? value : ""); I'm not well-versed in the Windows-specific parts of the GNU make code, but as far as I can tell GNU make would never construct an environment variable of that syntax, from any input. fg> Apparently CreateProcess really dislikes this because it would fg> give a most unpleasant error, returning an ERROR_MORE_DATA from fg> GetLastError. Although this makes sense now, the fact that it is fg> undocumented caused weeks of pain for us. CreateProcess() is a Windows function, not a GNU make function... ? I'm not exactly sure what it is you are looking for here? Thanks! -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
make bug report
Hello.I found a bug. (I think it may be a bug.)I use Cygnus make.exe on MS Window 2000.Dumping stack errors have occured in my PC.So, I'd like to report the error statusWhen you succeed solving the problem, reply with a mail to explain how to fix it, please...Have a good day...Bye...OS: MS Window2000c:\cygnus\bin> make -vGNU Make version 3.79.1, by Richard Stallman and Roland McGrath.Built for i686-pc-cygwinCopyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 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 APARTICULAR PURPOSE.The attached files are stack dump files... ÄÚ¸®¾Æ´Â ´ç½ÅÀ» »ç¶ûÇÕ´Ï´Ù --- ½Å³ª´Â °ÔÀÓ, ¹Ý°¡¿î Ä£±¸, ±× ¸ðµç °ÍÀÌ ÀÌ°÷¿¡! ´ëÇ¥ °ÔÀÓ ¸Þ°¡ Æ÷Å» http://game.korea.com make.exe.stackdump Description: Binary data
Re: Bug report
The makefile looks quite normal and simple to me. Executing the *.h file could have resulted from: - a missing/extraneous tab in the wrong place, or - a missing/extraneous line continuation character. Otherwise, please provide the makefile that produces the error (as this one apparently is not), as well as the exact output from make and its executed command lines. Regards, Johan Bezem CSK Software AG "Prof. Dr. Doeringer (FB Informatik)" wrote: > > Hi, there is a problem with make I cannot figure out at all. Hence I send > you the make-file causing the headaches. I am more than happy to supply > further information or give you access to my machine to do further tests. > Best regards, W. Doeringer > > PS.: Otherwise, I have been using make for years and it did not fail! > > > Name: XDebug.mk >XDebug.mkType: Plain Text (TEXT/PLAIN) > Encoding: BASE64 > > > ___ > Bug-make mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Bug report
Please keep the mails on the list (reply-to set). To start with, I just need the regular stdout from a normal call to make, using the problematic version, possibly with a binary correct (as attachment) version of the problematic makefile. If I need more, I'll shout. But then again: make version 3.77 is 'terribly' old. Could you try again using 3.79.1 or 3.80. and see if it still fails? Maybe Paul has some knowledge about such errors being present in older versions, however, I've only got experience since 3.79. Regards, Johan Bezem CSK Software AG "Prof. Dr. Doeringer (FB Informatik)" wrote: > > Dear Mr. Bezem, thanks for your reaction. I will send you the output of > the problematic version - could you advise me on the switches to use when > running make so that you get all the information you require? > The version info for make follows: > GNU Make version 3.77, by Richard Stallman and Roland McGrath. > Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98 > Free Software Foundation, Inc. > > Best regards, W. Doeringer > > On Mon, 16 Dec 2002, Johan Bezem wrote: > > > The makefile looks quite normal and simple to me. Executing the *.h file > > could have resulted from: > > - a missing/extraneous tab in the wrong place, or > > - a missing/extraneous line continuation character. > > Otherwise, please provide the makefile that produces the error (as this one > > apparently is not), as well as the exact output from make and its executed > > command lines. > > > > Regards, > > > > Johan Bezem > > CSK Software AG > > > > "Prof. Dr. Doeringer (FB Informatik)" wrote: > > > > > > Hi, there is a problem with make I cannot figure out at all. Hence I send > > > you the make-file causing the headaches. I am more than happy to supply > > > further information or give you access to my machine to do further tests. > > > Best regards, W. Doeringer > > > > > > PS.: Otherwise, I have been using make for years and it did not fail! > > > > > > > > > Name: XDebug.mk > > >XDebug.mkType: Plain Text (TEXT/PLAIN) > > > Encoding: BASE64 > > > > > > > > > ___ > > > Bug-make mailing list > > > [EMAIL PROTECTED] > > > http://mail.gnu.org/mailman/listinfo/bug-make > > ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Bug report
Hi, thanks for your reaction. I understand that the most sensible thing for us to do is to upgrade. I will do so and see whether the problem persists. More later, best regards Willi Doeringer On Mon, 16 Dec 2002, Johan Bezem wrote: > Please keep the mails on the list (reply-to set). > > To start with, I just need the regular stdout from a normal call to make, > using the problematic version, possibly with a binary correct (as > attachment) version of the problematic makefile. If I need more, I'll shout. > > But then again: make version 3.77 is 'terribly' old. Could you try again > using 3.79.1 or 3.80. and see if it still fails? Maybe Paul has some > knowledge about such errors being present in older versions, however, I've > only got experience since 3.79. > > Regards, > > Johan Bezem > CSK Software AG > > "Prof. Dr. Doeringer (FB Informatik)" wrote: > > > > Dear Mr. Bezem, thanks for your reaction. I will send you the output of > > the problematic version - could you advise me on the switches to use when > > running make so that you get all the information you require? > > The version info for make follows: > > GNU Make version 3.77, by Richard Stallman and Roland McGrath. > > Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98 > > Free Software Foundation, Inc. > > > > Best regards, W. Doeringer > > > > On Mon, 16 Dec 2002, Johan Bezem wrote: > > > > > The makefile looks quite normal and simple to me. Executing the *.h file > > > could have resulted from: > > > - a missing/extraneous tab in the wrong place, or > > > - a missing/extraneous line continuation character. > > > Otherwise, please provide the makefile that produces the error (as this one > > > apparently is not), as well as the exact output from make and its executed > > > command lines. > > > > > > Regards, > > > > > > Johan Bezem > > > CSK Software AG > > > > > > "Prof. Dr. Doeringer (FB Informatik)" wrote: > > > > > > > > Hi, there is a problem with make I cannot figure out at all. Hence I send > > > > you the make-file causing the headaches. I am more than happy to supply > > > > further information or give you access to my machine to do further tests. > > > > Best regards, W. Doeringer > > > > > > > > PS.: Otherwise, I have been using make for years and it did not fail! > > > > > > > > > > > > Name: XDebug.mk > > > >XDebug.mkType: Plain Text (TEXT/PLAIN) > > > > Encoding: BASE64 > > > > > > > > > > > > ___ > > > > Bug-make mailing list > > > > [EMAIL PROTECTED] > > > > http://mail.gnu.org/mailman/listinfo/bug-make > > > > ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Bug report
Hi, I have a problem with one single line in a Make-File that I cannot figure out at all. The problem is the same under version 3.77 and 3.79.1 under Linux. The errro message is as follows: make: execvp: ../CnGET.h: Keine Berechtigung make: *** [../CnGET.h] Fehler 127 The version info: GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i686-pc-linux-gnu Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. Report bugs to <[EMAIL PROTECTED]>. The make-file follows. Please look for the PROBLEM description. I would be more than happy to provide further information. Best regards, W. Döringer # + # (c) AG ProgrammbauFH Worms[EMAIL PROTECTED] + # + # HTTP Server in C++ + # + # Datei: HTTP/Server/C++/Code/Nachrichten/XDebug.mk # AutorIn: w.doeringer(@acm.org) # Beschreibung: Make Datei fuer die Nachrichten-Bibliothek # System: GNU - Linux [, Solaris] # Revision: 2002/12/16 # - # # --- Die Variable MakePStd muss auf das allgemeine Make-Verzeichnis zeigen --- include $(MakePStd)/C++/XDbgCpp.Inc # Projekt-spezifische Definitionen include ../../Make/XDbgCppProj.Inc # # Compiler Optionen # # --- Die generische Pseudo-Zieldatei - all:$(LibP)/NachrichtenDbg.a \ tCdaten \ tCn \ tCnDELETE\ tCnGET \ tCscanner\ tCscannerIn \ tNamen # # --- Die Bibliothek - # $(LibP)/NachrichtenDbg.a : \ NachrichtenDbg.a cp NachrichtenDbg.a $(LibP) # NachrichtenDbg.a: \ Cscanner.o \ Cdaten.o \ Cn.o \ CnDELETE.o \ CnGET.o \ Namen.o \ $(MakeP)/XDbgCppProj.Inc \ $(MakePStd)/C++/XDbgCpp.Inc $(LibrAriaN) $(LibOpt) $*.a Cscanner.o Cdaten.o Cn.o \ CnDELETE.o CnGET.o \ Namen.o # # --- Der Scanner $(QuellP)/Cscanner.h: \ $(BasisP)/CLog.h \ $(ZeileP)/Csymbol.h $(TouCH) $@ # Cscanner.o: \ $(BasisP)/Proj.h \ $(BasisP)/CLog.h \ $(QuellP)/Cscanner.h \ $(QuellP)/Cscanner.cpp \ $(MakeP)/XDbgCppProj.Inc \ $(MakePStd)/C++/XDbgCpp.Inc $(ComPileR) $(CompOpt) $(QuellP)/$*.cpp # # --- Cdaten $(QuellP)/Cdaten.h: \ $(BasisP)/CLog.h $(TouCH) $@ Cdaten.o: \ $(BasisP)/Proj.h \ $(BasisP)/CLog.h \ $(ConfiP)/Cconfig.h\ $(KonstP)/StatusCodes.h\ $(QuellP)/Cdaten.h \ $(QuellP)/Cdaten.cpp \ $(MakeP)/XDbgCppProj.Inc \ $(MakePStd)/C++/XDbgCpp.Inc $(ComPileR) $(CompOpt) $(QuellP)/$*.cpp # # --- Die Cnxxx $(QuellP)/Cn.h: \ $(QuellP)/ChttpNachricht.h $(TouCH) $@ # Cn.o: \ $(BasisP)/Proj.h \ $(BasisP)/CLog.h \ $(KonstP)/StatusCodes.h\ $(ZeileP)/CZrspLine.h \ $(ZeileP)/CZserver.h \ $(QuellP)/Cn.h \ $(QuellP)/CnGET.h \ $(QuellP)/Cn.cpp \ $(MakeP)/XDbgCppProj.Inc \ $(MakePStd)/C++/XDbgCpp.Inc $(ComPileR) $(CompOpt) $(QuellP)/$*.cpp # $(QuellP)/CnDELETE.h: \ $(ZeileP)/CZconnection.h \ $(ZeileP)/CZcontLocation.h\ $(ZeileP)/CZcontType.h\ $(ZeileP)/CZdate.h\ $(ZeileP)/CZhostPort.h\ $(ZeileP)/CZIfModifiedSince.h \ $(ZeileP)/CZnull.h\ $(ZeileP)/CZreqLine.h \ $(ZeileP)/CZrspLine.h \ $(QuellP)/Cscanner.h $(TouCH) $@ # CnDELETE.o: \ $(BasisP)/Proj.h \ $(BasisP)/CLog.h \ $(BasisP)/cctypeProj.h\ $(KonstP)/Codes.h \ $(KonstP)/StatusCodes.h \ $(ConfiP)/Cconfig.h
Re: Bug report
Hi, You didn't send the full makefile, since the includes are missing. Make apparently is considering the line "$(QuellP)/CnGET.h" a command to be executed, where CnGET.h probably doesn't have execute permissions. Look for the _exact_ definitions of variables like 'QuellP' and 'StreaP' (including leading/trailing spaces, tabs, etc!!) Echo them (in delimiters), and look at the _binary_ output (pipe into a file and take a hex-editor or sth.) I cannot place your remark "Please note that the exact copy of this line works with CnGET.o below!". The line below is never an exact copy. So I have no clue waht you intend to say there. I know, that, especially in such a case, it's quite difficult, but if you're having problems with a specific makefile, try to remove from that makefile as much as you can to create the smallest possible testcase that still shows the unexplainable behavior. First of all, you may notice something that never occurred to you before, possibly resolving your problem yourself, secondly, it will reduce the time we need to spend scanning for errors. We are more than willing to help, but the debugging of your makefiles will remain your work ;-) Regards, Johan Bezem CSK Software AG "Prof. Dr. Doeringer (FB Informatik)" wrote: > > Hi, I have a problem with one single line in a Make-File that I cannot > figure out at all. The problem is the same under version 3.77 and > 3.79.1 under Linux. > The errro message is as follows: > > make: execvp: ../CnGET.h: Keine Berechtigung > make: *** [../CnGET.h] Fehler 127 > > The version info: > > GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. > Built for i686-pc-linux-gnu > Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 > Free Software Foundation, Inc. > Report bugs to <[EMAIL PROTECTED]>. > > The make-file follows. > Please look for the PROBLEM description. > > I would be more than happy to provide further information. > Best regards, W. Döringer > <...> > $(KonstP)/Codes.h \ > $(KonstP)/StatusCodes.h \ > $(ConfiP)/Cconfig.h \ > $(ZeileP)/Csymbol.h \ > $(QuellP)/CnDELETE.h \ > $(QuellP)/CnDELETE.cpp\ > $(MakeP)/XDbgCppProj.Inc \ > $(MakePStd)/C++/XDbgCpp.Inc > > $(ComPileR) $(CompOpt) $(QuellP)/$*.cpp > # > # > # PROBLEM: The line $(StreaP)/fstreamProj.h > # causes the problem. I tried OTHER > # filenames and some of them worked! > # Please note that the exact copy of > # this line works with CnGET.o below! > $(QuellP)/CnGET.h: \ > $(StreaP)/fstreamProj.h \ > $(ZeileP)/CZconnection.h \ > $(ZeileP)/CZcontLength.h \ > $(ZeileP)/CZcontLocation.h\ > $(ZeileP)/CZcontType.h\ > $(ZeileP)/CZdate.h\ > $(ZeileP)/CZhostPort.h\ > $(ZeileP)/CZIfModifiedSince.h \ > $(ZeileP)/CZnull.h\ > $(ZeileP)/CZreqLine.h \ > $(ZeileP)/CZrspLine.h \ > $(QuellP)/Cdaten.h\ > $(QuellP)/Cscanner.h > $(TouCH) $@ > # > CnGET.o: \ > $(BasisP)/Proj.h \ > $(BasisP)/CLog.h \ > $(BasisP)/cctypeProj.h\ > $(KonstP)/Codes.h \ > $(KonstP)/StatusCodes.h \ > $(ConfiP)/Cconfig.h \ > $(ZeileP)/Csymbol.h \ > $(StreaP)/fstreamProj.h \ > $(QuellP)/CnGET.h \ > $(QuellP)/CnGET.cpp \ > $(MakeP)/XDbgCppProj.Inc \ > $(MakePStd)/C++/XDbgCpp.Inc > $(ComPileR) $(CompOpt) $(QuellP)/$*.cpp <...> ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Brahms bug report
Hello! I have a problem when trying to make Brahms application. Logfiles are attached. Source file name is "brahms-1.02-kde3.tgz". Say please, what can i do to avoid this problem? With respect, Aleksej. June 13, 2003 Brahms-logs.zip Description: Zip archive ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: bug report
%% "Sandeep Nema" <[EMAIL PROTECTED]> writes: sn> In one of my makefile, I have following conditional syntax: sn> ADDONS_DB_C = $(EXCLUDEFWKLIB?:$(TMP_ADDONS_DB_C)) sn> This gives me an error for MACRO SUBSTITUTION First, this is not a proper bug report. Whenever you report a bug you must always specify the version of the program you're using, the type of system you're using it on, and the complete, _exact_ error message you received (best is to cut and paste it into your report). Plus, any other information you think might be useful. Second, there is nowhere in GNU make that the text "macro substitution" (in any case) exists, much less is printed. Finally, there is no "?:" macro operator in GNU make, so I don't know what the above construct might be supposed to mean. -- --- 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: bug report
sorry about incomplete bug-report. Following are the details and further questions. GNU make version: 3.80 O/S: AIX 5.0 We used "?:" macro substitution on tru64 platform with their make, and it works as following: X= $(EXCLUDE_X?:$(TMP_ADD_X)) in the above if EXCLUDE_X is defined then X will be empty, if not defined it will be equal to TMP_ADD_X. This does not give any error while making with GNU make on AIX, but does not work, i.e. does not substitute X with TMP_ADD_X. I feel, if there is no "?:" operator, it should give a syntax error. Do you have any shorter alternative in GNU make other than "ifdef". Thanks a lot, Sandeep Nema >>> "Paul D. Smith" <[EMAIL PROTECTED]> 01/03/04 09:53AM >>> %% "Sandeep Nema" <[EMAIL PROTECTED]> writes: sn> In one of my makefile, I have following conditional syntax: sn> ADDONS_DB_C = $(EXCLUDEFWKLIB?:$(TMP_ADDONS_DB_C)) sn> This gives me an error for MACRO SUBSTITUTION First, this is not a proper bug report. Whenever you report a bug you must always specify the version of the program you're using, the type of system you're using it on, and the complete, _exact_ error message you received (best is to cut and paste it into your report). Plus, any other information you think might be useful. Second, there is nowhere in GNU make that the text "macro substitution" (in any case) exists, much less is printed. Finally, there is no "?:" macro operator in GNU make, so I don't know what the above construct might be supposed to mean. -- --- 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: bug report
%% "Sandeep Nema" <[EMAIL PROTECTED]> writes: sn> GNU make version: 3.80 sn> O/S: AIX 5.0 sn> We used "?:" macro substitution on tru64 platform with their make, and sn> it works as following: sn> X= $(EXCLUDE_X?:$(TMP_ADD_X)) sn> in the above if EXCLUDE_X is defined then X will be empty, if not sn> defined it will be equal to TMP_ADD_X. What does "defined" mean here? Does it mean "has some non-empty value", or does it mean "has been set in any way, including to the empty value"? sn> This does not give any error while making with GNU make on AIX, sn> but does not work, i.e. does not substitute X with TMP_ADD_X. Correct. This syntax is not supported by GNU make. sn> I feel, if there is no "?:" operator, it should give a syntax sn> error. Why would it give a syntax error, when that's not a syntax error? sn> Do you have any shorter alternative in GNU make other than sn> "ifdef". Since you didn't specify exactly what behavior "?:" provides I can't say for sure, but look up the ?= assignment operator in the GNU make manual. -- --- 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: bug report
please see my response/clarification below in bold with > >>> "Paul D. Smith" <[EMAIL PROTECTED]> 01/05/04 10:08AM >>> %% "Sandeep Nema" <[EMAIL PROTECTED]> writes: sn> GNU make version: 3.80 sn> O/S: AIX 5.0 sn> We used "?:" macro substitution on tru64 platform with their make, and sn> it works as following: sn> X= $(EXCLUDE_X?:$(TMP_ADD_X)) sn> in the above if EXCLUDE_X is defined then X will be empty, if not sn> defined it will be equal to TMP_ADD_X. What does "defined" mean here? Does it mean "has some non-empty value", or does it mean "has been set in any way, including to the empty value"? -> has been set in any way, including to the empty value sn> This does not give any error while making with GNU make on AIX, sn> but does not work, i.e. does not substitute X with TMP_ADD_X. Correct. This syntax is not supported by GNU make. sn> I feel, if there is no "?:" operator, it should give a syntax sn> error. Why would it give a syntax error, when that's not a syntax error? -> You mentione in your previous answer that "?:" is not supported syntax, shouldn't it give any kind of error if its used in the makefile. sn> Do you have any shorter alternative in GNU make other than sn> "ifdef". Since you didn't specify exactly what behavior "?:" provides I can't say for sure, but look up the ?= assignment operator in the GNU make manual. -> X = $(EX_X?:ADD_X)) if EX_X is NOT defined, X = ADD_X else X contains an empty value. -- --- 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: bug report
%% "Sandeep Nema" <[EMAIL PROTECTED]> writes: sn> has been set in any way, including to the empty value OK. sn> You mentione in your previous answer that "?:" is not supported sn> syntax, shouldn't it give any kind of error if its used in the sn> makefile. Just because the syntax doesn't do the same thing it does in other makes, doesn't mean that it's not legal syntax in GNU make. ps> Since you didn't specify exactly what behavior "?:" provides I ps> can't say for sure, but look up the ?= assignment operator in the ps> GNU make manual. sn> X = $(EX_X?:ADD_X)) sn> if EX_X is NOT defined, X = ADD_X sn> else X contains an empty value. Yes, but as I mentioned you didn't specify what "defined" means (your reply above makes it clear now). The only way to do exactly the above is using if statements. You can combine them with call, eval, etc. to define your own macro to make it slightly easier for the user, if you use this syntax a lot. The ?= operator will do what you want if you're trying to define a variable to a value if it itself doesn't have one, but it won't help if you're trying to define a variable to a value if some other variable doesn't have one. -- --- 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
bug report : make --help
[root@localhost ~]# make --help 用法：make [选项] [目标] ... 选项： -b, -m 忽略兼容性。 -B, --always-make 无条件 make 所有目标。 -C DIRECTORY, --directory=DIRECTORY 在执行钱先切换到 DIRECTORY 目录。 -d 打印大量调试信息。 --debug[=FLAGS] 打印各种调试信息。 -C DIRECTORY, --directory=DIRECTORY “在执行钱先切换到 DIRECTORY 目录。 ” should be “在执行前先切换到 DIRECTORY 目录。 ” clo...@gmail.com ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
gmake 3.79 bug report
Hi, I am not sure if this is a problem with gmake or makedepend. Please let me know. Thanks. -- sape(122)% gmake -n cc -c ../include.h sape(123)% cat Makefile VPATH = .. gated_trace.o: gated_trace.c $(CC) -c $< # DO NOT DELETE ../gated_trace.o: ../include.h sape(124)% ls Makefile sape(125)% sape(125)% ls .. gated_trace.c include.h obj/ sape(126)% gmake -v GNU Make version 3.79, by Richard Stallman and Roland McGrath. Built for i386-unknown-freebsdelf3.2 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 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. Report bugs to <[EMAIL PROTECTED]>. sape(127)% uname -a FreeBSD sape.cs.bell-labs.com 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Tue May 18 04:05:08 GMT 1999 jkh@cathair:/usr/src/sys/compile/GENERIC i386 sape(128)%
Re: make bug report
I'm sorry, but first you're using Cygnus GNU make which is not identical to the standard GNU make provided by the GNU project; you need to direct your problem to Cygnus/Red Hat. Second, unfortunately we don't have the resources at GNU to handle Windows-specific issues; certainly we can't do anything with a Windows dump file. You might try asking on the [EMAIL PROTECTED] mailing list, which has subscribers using GNU make on Windows platforms. Probably they won't be able to do much with the stack dump either; you will need to give a sample makefile that shows the problem, or at least a description of what is going on when the failure occurs. -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Brahms bug report
On Sat, Jun 14, 2003 at 01:59:46PM +0400, Aleksej Mazunin wrote: > Hello! > I have a problem when trying to make Brahms application. > Logfiles are attached. Could you please attach them as plain text files. Neither gunzip nor bunzip2 understand the format of the .zip file you have attached. Maybe it is obvious from the log-files, but still providing a summary of the problem you see would help finding the cause of the problem. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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
Re: bug report : make --help
On Tue, 2014-08-12 at 14:48 +0800, clo...@gmail.com wrote: > [root@localhost ~]# make --help > -C DIRECTORY, --directory=DIRECTORY > “在执行钱先切换到 DIRECTORY 目录。 ” > > should be > > “在执行前先切换到 DIRECTORY 目录。 ” Hi; Translations for GNU projects, including GNU make, are handled by the Translation Project. Information on how to reach the translators can be found here: http://translationproject.org/domain/make.html Thanks for your effort to improve GNU make! ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
gcc on cygwin bug report
I use cygwin on windows2000 server and I install arm-elf-gcc for cygwin. $ arm-elf-gcc -v Reading specs from /usr/local/cross-gcc/arm-elf//lib/gcc-lib/arm-elf/3.0/specs Configured with: ../gcc-3.0/configure= --prefix=3D/usr/local/cross-gcc/arm-elf/ --t arget=3Darm-elf --with-newlib --enable-multilib --with-gnu-as= --with-gnu-ld Thread model: single gcc version 3.0 when I link use arm-elf-gcc ,but it output nothing (neither error nor successful output) My command and result is: arm-elf-gcc -e _start -N -Tmy.link -nostdlib -Wl,--EB -o rom.bin abc.o timer.o abcd.o console.o p00.o kkk.o ... (with a lot of .o files) make: *** [rom.bin] Error 128 but when I use the same command in windows 2000 SERVER security mode with command line, arm-elf-gcc output correct result:it output rom.bin I think I maybe a error in gcc or make does anyone tell me how to solve this problem? ren donghua [EMAIL PROTECTED] ¡¡2002-07-16 nf¤zf¢)à+-è&jG ê+m§ÿæj)`ê+ùYùb²Ø§~Ûº
GNU Make 3.79.1 Bug-Report?
Dear Madams and Sirs, for more then 5 years we used the GNU Make version 3.76.1 at PCs with OS Win98. Now we changed to GNU Make version 3.79.1 which comes with the mingw32 Compiler. Since this time we are not able to run the old makefiles of already existimg projects. The result for the following lines on the same PC with OS Win98 is completely different. all: cd test dir > content.txt cd .. Make 3.76.1 does the change of directory as expected, make 3.79.1 does not Is this problem of the PC-Binary already known and is there a later version with a bugfix availiable? Thanks for your help in advance and kind regards Gerd Igelmann Germany Revision Info: GNU Make version 3.76.1, by Richard Stallman and Roland McGrath. Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97 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. Report bugs to <[EMAIL PROTECTED]>. GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for mingw32 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 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. Report bugs to <[EMAIL PROTECTED]>. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Bug Report (SUN Sparc Kernel-2.4)
Following your directions (Gentoo handbook) Installing Necessary System Tools (Section 9) At 9.a. Device Manager: udev is not available for unmerging and when I attempt to merge devfsd I get the following error/bug !!! ERROR: sys-fs/devfsd-1.3.25-r9 failed. !!! Function src_compile line 566, Exitcode 2 !!! emake failed NOTE: Apparently UDEV is not supported for 2.4 kernel, but 2.4 kernel is default for Sparc 64 bit processor). -lt Lawrence Thorne CEO/President Thorne Digital Media Group, Inc. 1133 Broadway Ste #606 New York, NY 10010 Email: [EMAIL PROTECTED] Office: (212) 206-7804 Fax: (212) 504-3169 Cell: 646-734-8989 24 hour Support: [EMAIL PROTECTED] This email may contain material that is confidential or proprietary to Thorne Digital Media Group, Inc. and is intended solely for use by the intended recipient. Any review, reliance or distribution of such material by others, or forwarding of such material without express permission, is strictly prohibited. If you are not the intended recipient, please notify the sender and destroy all copies. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Bug report for "make" documentation
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
MAKE's Internet web page bug report
bug-make@gnu.org Hello - I believe I have found a bug in the online Internet web pages for "make". I am looking at http://www.gnu.org/software/make/manual/make.html#How-Make-Works I see the following two paragraphs, each of which has the same basic error: "Before recompiling an object file, make considers updating its prerequisites, the source file and header files. This makefile does not specify anything to be done for them--the '.c' and '.h' files are not the targets of any rules--so make does nothing for these files. But make would update automatically generated C programs, such as those made by Bison or Yacc, by their own rules at this time." and "After recompiling whichever object files need it, make decides whether to relink edit. This must be done if the file edit does not exist, or if any of the object files are newer than it. If an object file was just recompiled, it is now newer than edit, so edit is relinked. " The Problem is: The system does NOT "recompile an object file" The system compiles and/or recompiles source code files. I suggest that you change the wording to say something to the effect of: ... when the system recompiles source files or relinks requisite object files in order to generate a new object file ..." -- Terry McCarty 3...@comcast.net wa5nti ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU Make 3.79.1 Bug-Report?
%% "Gerd Igelmann" <[EMAIL PROTECTED]> writes: gi> for more then 5 years we used the GNU Make version 3.76.1 at PCs gi> with OS Win98. Now we changed to GNU Make version 3.79.1 which gi> comes with the mingw32 Compiler. Since this time we are not able gi> to run the old makefiles of already existimg projects. gi> The result for the following lines on the same PC with OS Win98 is gi> completely different. gi> all: gi> cd test gi> dir > content.txt gi> cd .. gi> Make 3.76.1 does the change of directory as expected, make 3.79.1 gi> does not The short answer is you need to discuss this with the people distributing the MINGW port of GNU make. The longer answer is that the behavior in 3.79.1 is correct according to the make standard, and every implementation of make on any UNIX or UNIX-like system behaves that way. In make each line of a command script is run as a separate step. In UNIX-y systems, the current working directory is local to that processes environment (child processes inherit their environment from their parents), and also no child process can ever modify the environment of its parent. That combination means that each individual line of a make rule (run as a child process of make) can modify its own working directory value, but when that line is done and the process exits, any changes made to the working directory are gone; they are not reflected in the environment of the parent (make). In Windows and DOS, the COMMAND.COM works differently in that the current working directory value is global, to some extent, so any change to it, in any process, effects future processes. This is the behavior you were seeing with the older version of GNU make. Although the MINGW port is not actually supported on this list as it's created by a 3rd party (although GNU make 3.81 will merge that port in officially), I suspect that the MINGW port is using something other than COMMAND.COM to invoke its commands. If you like you can go get the source to GNU make from ftp://ftp.gnu.org/gnu/make/ (the FSF doesn't distribute pre-built versions of its software on the FTP site). Unpack it and read the README.W32 and README.DOS files and they will explain how to build GNU make to use basic COMMAND.COM, whereupon you might get back the older behavior. Finally, note that what you are doing above would be written in a standard makefile as: all: cd test; dir > content.txt By putting these two commands on one line they are both executed by the same process, which means the "cd" command is still in effect when the "dir" is run. We don't have to "cd ..", because that happens automatically when the process ends. I don't know if whatever shell you're using with your port supports syntax like this or not. -- --- 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU Make 3.79.1 Bug-Report?
> From: "Gerd Igelmann" <[EMAIL PROTECTED]> > Date: Tue, 20 Jan 2004 20:14:27 +0100 > > all: > cd test > dir > content.txt > cd .. > > Make 3.76.1 does the change of directory as expected, make 3.79.1 does not As Paul points out, this is most probably a shell issue, not a Make issue. So the first thing to check is what shell is invoked by each version of Make to run these commands. If, by any chance, Make 3.79.1 invokes a ported Bash, then you will indeed see this behavior, since Bash restores the original working directory when it exits, to play the Unix compatibility game. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU Make 3.79.1 Bug-Report?
> Date: Tue, 20 Jan 2004 21:47:21 -0500 > From: "Paul D. Smith" <[EMAIL PROTECTED]> > > In Windows and DOS, the COMMAND.COM works differently in that the > current working directory value is global, to some extent, so any change > to it, in any process, effects future processes. Actually, it's not up to COMMAND.COM to cause this. On Windows, the working directory is global to all processes in a given ``session'', so any change of the cwd by any process running in the session affects all the other processes in that session. > Finally, note that what you are doing above would be written in a > standard makefile as: > > all: > cd test; dir > content.txt This will work only if the shell invoked to run such commands supports multiple commands in a single command line. COMMAND.COM that comes with Windows 9x, which is the case in point, does not. (The DJGPP port of Make does support this by using the internal emulator of COMMAND.COM implemented in the C library's `system' function that interprets special characters such as `;' and `>', but the MinGW port probably uses the Microsoft runtime, so it can't.) ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
RE: Bug Report (SUN Sparc Kernel-2.4)
A quick google for the error message turned up a fourth line, saying: !!! If you need support, post the topmost build error, NOT this status message. However, this list is for bugs in gnu make and your problem is far more likely to be with something gentoo-specific. We don't know anything about gentoo here. When reporting a make bug, you'd want to supply the necessary part of the makefile, the output from make and an explanation of why you think make is in error. (None of the output you supplied was from make.) - Martin's Outlook, BlueArc Engineering From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence W. Thorne Sent: Sunday, July 09, 2006 16:28 To: bug-make@gnu.org Subject: Bug Report (SUN Sparc Kernel-2.4) Following your directions (Gentoo handbook) Installing Necessary System Tools (Section 9) At 9.a. Device Manager: udev is not available for unmerging and when I attempt to merge devfsd I get the following error/bug !!! ERROR: sys-fs/devfsd-1.3.25-r9 failed. !!! Function src_compile line 566, Exitcode 2 !!! emake failed NOTE: Apparently UDEV is not supported for 2.4 kernel, but 2.4 kernel is default for Sparc 64 bit processor). -lt Lawrence Thorne CEO/President Thorne Digital Media Group, Inc. 1133 Broadway Ste #606 New York, NY 10010 Email: [EMAIL PROTECTED] Office: (212) 206-7804 Fax: (212) 504-3169 Cell: 646-734-8989 24 hour Support: [EMAIL PROTECTED] This email may contain material that is confidential or proprietary to Thorne Digital Media Group, Inc. and is intended solely for use by the intended recipient. Any review, reliance or distribution of such material by others, or forwarding of such material without express permission, is strictly prohibited. If you are not the intended recipient, please notify the sender and destroy all copies. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
bug report acknowledgments should be the default!
I noticed that when submitting bugs to bug-*@gnu.org, unlike other bug submission by mail systems, e.g., Deb bugs of Debian, the user receives no cheery auto reply acknowledging the bug was ever even received and didn't go into a black hole, or expecting the user to dig out what happened to his submission via poking around the website. Let's the advanced user disable notifications like they can in Debian. For the default state, please enable auto acknowledgments of bug mail received, like Debian does. Anybody reading this? Anybody get this? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
bug report (v3.77): target specific variable values
Essentially, when using multiple target specific variable assignments with multiple targets, some of such variable assignments destroy other variable values. The variable values that are destroyed are those of other target specific assignments. The makefile demonstrating the problem runs as follows: # propogate value of FLAG1 targ1: targ2 targ1: FLAG1 = some_particular_val # propogate value of FLAG2 targ2: targ3 @echo MAKING TARG2: flag1 is % $(FLAG1) %, flag2 is % $(FLAG2) % targ2: FLAG2=some_other_val # screen output MAKING TARG2: flag1 is % some_particular_val %, flag2 is % some_other_val % # FLAG1 no longer defined. targ3: @echo MAKING TARG3: flag1 is % $(FLAG1) %, flag2 is % $(FLAG2) % # screen output MAKING TARG3: flag1 is % %, flag2 is % some_other_val % ### You may wish to get rid of the comments when examining the results during running the make script. They add a little extra line noise. At any rate, when making targ3, I thought that I should be told that the value of FLAG1 is "some_particular_val". The value of FLAG1 while making targ3 is actually displayed as undefined. The "higher level" value of FLAG1, associated with the independent target that calls in targ2, was lost during the making of targ3. In the makefile that I have been writing elsewhere, the variable value associated with the the independent target was kept, and the variable values associated with the dependent targets were lost. This is a different result, but a similar problem. Is something within the make sourcecode stomping something else? My platform is cygwin b20, on winnt. The make version is 3.77, and was compiled from source that I downloaded from the prep.ai.mit.edu site. A tarball containing another copy of the same makefile, and my config.h is enclosed. I hope outlook sends it out in MIME format. I hope this bug report helps. Thanks, Dean Fitzgerald make_report.tar
Re: bug report acknowledgments should be the default!
>>>>> "PS" == Paul Smith writes: PS> If you want a bug report to be filed and acknowledged, then you want: PS> https://savannah.gnu.org/bugs/?func=additem&group=make Thanks for answering! Well that's not the advertised way to submit bugs. You advertise bug-*@gnu.org. PS> The FSF does not use an email-based bug tracker, like Debian; we use PS> Savannah. OK, but Savannah should then be made to send acknowledgments by default. The power users could easily adjust some of their settings to turn them back off. Just telling you how it all looks from this end. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug report acknowledgments should be the default!
On Thu, 2011-04-14 at 08:57 +0800, jida...@jidanni.org wrote: > >>>>> "PS" == Paul Smith writes: > PS> If you want a bug report to be filed and acknowledged, then you want: > PS> https://savannah.gnu.org/bugs/?func=additem&group=make > Thanks for answering! Well that's not the advertised way to submit bugs. > You advertise bug-*@gnu.org. Both the mailing list and Savannah are discussed on the make home page, but you're right, this should be made more clear. It does clearly say that bug-make is a "main discussion list", however, and so I wouldn't expect people to think that messages to that list would become bug reports and automatically acknowledged, a la Debian's BTS etc. > PS> The FSF does not use an email-based bug tracker, like Debian; we use > PS> Savannah. > OK, but Savannah should then be made to send acknowledgments by default. > The power users could easily adjust some of their settings to turn them back > off. I believe that if you file a bug with Savannah it will send you email both when you file it and whenever it is updated. If something about Savannah isn't working the way you want, you should file a bug against Savannah itself (the Savannah project on Savannah). I don't have any ability to modify or fix the Savannah behavior. Cheers! -- --- Paul D. Smith Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net "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
Re: bug report acknowledgments should be the default!
On Thu, 2011-04-14 at 07:28 +0800, jida...@jidanni.org wrote: > I noticed that when submitting bugs to bug-*@gnu.org, unlike other bug > submission by mail systems, e.g., Deb bugs of Debian, the user receives > no cheery auto reply acknowledging the bug was ever even received and > didn't go into a black hole, or expecting the user to dig out what > happened to his submission via poking around the website. > > Let's the advanced user disable notifications like they can in Debian. > For the default state, please enable auto acknowledgments of bug mail > received, like Debian does. > > Anybody reading this? > Anybody get this? If you want a bug report to be filed and acknowledged, then you want: https://savannah.gnu.org/bugs/?func=additem&group=make The FSF does not use an email-based bug tracker, like Debian; we use Savannah. This mailing list is for discussion about bugs. Sometimes those discussions result in a fix and sometimes not, but it's not the case that every message to this list is automatically tracked as a bug report. Only Savannah bug reports are officially tracked. -- --- Paul D. Smith Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net "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
Re: bug report acknowledgments should be the default!
PS> however, and so I wouldn't expect people to think that messages to PS> that list would become bug reports and automatically acknowledged, a PS> la Debian's BTS etc. Anyways from all the GNU man pages (but not exactly make's, true, but we just remember bug-make@gnu.org anyway and wouldn't check the man page), one thinks filing a bug against a package/program is as easy as sending it to bug-*@gnu.org. That some assign a number and autoreply, like bug-gnu-em...@gnu.org (which in fact now uses Debbugs software), and some don't, and some even... well, let's say reports are very likely to fall through the cracks and be wasted... is something I would hope you fellows would unify behind the scenes. Well OK, that those addresses have "bug" in them means someone will not let them fall through the cracks one hopes. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug report (v3.77): target specific variable values
I believe this is an instance of a problem I've fixed for the next version of GNU make, which should be appearing fairly soon. If you like I can add you to the pretest list, if you want to try it and see if it solves your problem. -- --- Paul D. Smith <[EMAIL PROTECTED]> Network Management Development "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Bug report & solution: make-3.80: Win32 linking error.
Hello! It seems that script for assembling binaries of make-3.80 GNU make utility for Win32 platform is incorrect. PROBLEM The problem occures when one launches the "build_w32.bat" script with all other settings made according to the README. There are messages about unresolved external symbols on the link stage. Executable binaries doesn't appear. SOLUTION Add some strings in "build_w32.bat" that compile hash.c file. (The correct version of "build_w32.bat" script, named as "build_w32.bat.txt", is attached to this message, pay attention on the strings number: 68, 69, 133, 134 of the attached file). Good Luck! -- Andrey V. Ovchar Software developer. The Budker Institute of Nuclear Physics. set make=gnumake +if not exist config.h copy config.h.W32 config.h cd w32\subproc echo "Creating the subproc library" %ComSpec% /c build.bat cd ..\.. del link.dbg link.rel del config.h copy config.h.W32 config.h echo off echo "Creating GNU make for Windows 95/NT" echo on if not exist .\WinDebug\nul mkdir .\WinDebug cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D TIVOLI /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c variable.c echo WinDebug\variable.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c rule.c echo WinDebug\rule.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c remote-stub.c echo WinDebug\remote-stub.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c commands.c echo WinDebug\commands.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c file.c echo WinDebug\file.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c getloadavg.c echo WinDebug\getloadavg.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c default.c echo WinDebug\default.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c signame.c echo WinDebug\signame.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c expand.c echo WinDebug\expand.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c dir.c echo WinDebug\dir.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c main.c echo WinDebug\main.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c getopt1.c echo WinDebug\getopt1.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c job.c echo WinDebug\job.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c read.c echo WinDebug\read.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/include /D _DEBUG /D WINDOWS32 /D WIN32 /D _CONSOLE /D HAVE_CONFIG_H /FR.\WinDebug/ /Fp.\WinDebug/%make%.pch /Fo.\WinDebug/ /Fd.\WinDebug/%make%.pdb /c version.c echo WinDebug\version.obj >>link.dbg cl.exe /nologo /MT /W3 /GX /Zi /YX /Od /I . /I glob /I w32/incl
Make for cross-compilation/Feature Request, not Bug Report
Hello, the GNU GCC and Binutils packages have the following feature: when compiled for cross compilation, e.g., for TARGET=arm-none-eabi they are compiled with the names $TARGET-gcc, $TARGET-nm, etc. Various programs such as the compiler driver, the linker etc. automatically change their search paths, such as the standard include or library directories, which basically change from $PREFIX/lib to $PREFIX/$TARGET/lib etc. In general, make is oblivious to these changes, and has predefined macros, such as CC, etc. to allow a single Makefile to be used for several environments, both hosted and cross-compilation. However, the Info node (make.info)Libraries/Search documents the "Directory Search for Link Libraries" feature. This feature does not extend to cross compilation environments: make does not take a possible cross-compilation environment into account. That is, the compiled-in path /lib, /usr/lib, and PREFIX/lib is not changed to e.g., PREFIX/TARGET/lib. Makefiles that use the feature will require rework for cross-compilation environments, which is a shame. It does not seem difficult to extend the current feature to work in cross-compilation environments. E.g., the name of the executable could be examined to determine if it was invoked with a base name of XXX-make and to use XXX as the prefix. At the same time, the location of the executable would need to be determined to instantiate PREFIX. By referring to the same executable by different names (multiple hard links to the file), different cross compilation environments could be supported by one executable. A related change would be to instantiate the predefined macros such as CC from gcc to $TARGET-gcc in those cases where CC is initialized to gcc. Regards, Konrad Schwarz BEGIN:VCARD VERSION:2.1 N:Schwarz;Konrad FN:Konrad Schwarz ORG:Siemens AG;CT SE 2 TITLE:Principal Engineer TEL;WORK;VOICE:+49 (89) 636-53579 TEL;WORK;FAX:+49 (89) 636-45450 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;53 518;Siemens AG=0D=0ACT SE 2;M=FCnchen;;81730;Germany LABEL;WORK;ENCODING=QUOTED-PRINTABLE:53 518=0D=0ASiemens AG=0D=0ACT SE 2=0D=0AM=FCnchen 81730=0D=0AGermany ADR;POSTAL;ENCODING=QUOTED-PRINTABLE:;;Siemens AG=0D=0ACT SE 2;M=FCnchen;;81730;Germany LABEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Siemens AG=0D=0ACT SE 2=0D=0AM=FCnchen 81730=0D=0AGermany EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20060130T101011Z END:VCARD ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug report & solution: make-3.80: Win32 linking error.
%% Regarding Bug report & solution: make-3.80: Win32 linking error.; you %% wrote: n> It seems that script for assembling binaries of make-3.80 GNU make n> utility for Win32 platform is incorrect. This problem has been reported and fixed, and the fix will be available in the next version of GNU make. Patches are available attached to the bug reports at http://savannah.gnu.org/projects/make -- --- 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
make-3.81: bug-report: function abspath works incorrectly on widows
Hello, FSF community. I found a bug in GNU Make 3.81 on MS Windows. So let me discuss it and suggest a patch. The problem take place in function abspath when trying to expand paths which are already full qualified. makefile for test is the next: --- $(info test - $(abspath C:/)) $(info test - $(abspath C:)) $(info test - $(abspath C:/Windows/system32/)) $(info test - $(abspath C:/Windows/system32/..)) $(info test - $(abspath C:/Windows/system32/../..)) $(info test - $(abspath C:/../../)) $(info test - $(abspath C:/../..)) $(info test - $(abspath .)) $(info test - $(abspath ../..)) --- Output with Gnu Make 3.81 (current directory is H:/make-3.81): --- test - H:/make-3.81/C: test - H:/make-3.81/C: test - H:/make-3.81/C:/Windows/system32 test - H:/make-3.81/C:/Windows test - H:/make-3.81/C: test - H: test - H: test - H:/make-3.81 test - H:/make-3.81 make: *** No targets. Stop. --- Output after apppling my patch for the function.c : --- test - C: test - C: test - C:/Windows/system32 test - C:/Windows test - C: test - C: test - C: test - h:/make-3.81 test - h: make_msvc.net2003: *** No targets. Stop. --- Suggested patch is in attachment. function.c.patch Description: Binary data ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: make-3.81: bug-report: function abspath works incorrectly onwidows
Vitaly Murashev wrote on 26 June 2008 11:45: >> . It doesn't produce fully qualified file names from drive-relative >>names such as "d:foo/bar". > > Not really. My patch produces the same output for "d:foo/bar" > and for "d:/foo/bar", the result is "d:/foo/bar" That's a mistake, because the two are not the same. The path "d:foo/bar" without a slash after the colon means "foo/bar relative to the current working directory on the D: drive". Unless your working directory is the root dir, that's not the same thing as "d:/foo/bar". 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 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 dependent libraries... pass_all checking for x86_64-pc-linux-gnu-ar... x86_64-pc-linux-gnu-ar checking for x86_64-pc-linux-gnu-strip... x86_64-pc-linux-gnu-strip checking for x86_64-pc-linux-gnu-ranlib... x86_64-pc-linux-gnu-ranlib checking command to parse /usr/bin/nm -B output from x86_64-pc-linux-gnu-gcc object... ok checking for dlfcn.h... yes checking for objdir... .libs checking if x86_64-pc-linux-gnu-gcc supports -fno-rtti -fno-exceptions... no checking for x86_64-pc-linux-gnu-gcc option to produce PIC... -fPIC -DPIC checking if x86_64-pc-linux-gnu-gcc PIC flag -fPIC -DPIC works... yes checking if x86_64-pc-linux-gnu-gcc static flag -static works... yes checking if x86_64-pc-linux-gnu-gcc supports -c -o file.o... yes checking if x86_64-pc-linux-gnu-gcc supports -c -o f
[Bug report] Make doesn't know $@ when referenced in the prerequisites
Hi, (NOTE: For details on versions used and whatnot see the end of the e-mail, should apply to all of them, AFAIK.) I know that this is a corner case, but given a Makefile such as this one: """ Makefile """ bar: $(@:%r=foo%z) @echo End foobaz: @echo The """ GNU Make Output: End NetBSD Make Output: The End Make fails to read $@ (aka, it's empty). I suppose you set all the special variables $@, $^, $< and some other I might be forgeting about after checking the prerequisites, so that they can all be set in one go. That behaviour breaks this kind of construct. (Curiously enough it works in bmake. I didn't expect it to, as it uses pattern matching expansion) Furthermore, it can be taken further away. See for example this other Makefile . """ Makefile """ bar: $(@:%r=foo%z) $(<:%z=%r) @echo End foobar: @echo Very foobaz: @echo The """ GNU Make Output: End NetBSD Make Output: The End """ Here NetBSD Make screws it too, as they both ignore $< that could be set up by the time it's requested (will report it to them too, when I find the time). For the sake of giving details, I'm using GNU Make 4.2.1 and bmake 20170201-1 as reported by an updated ArchLinux x86_64. I have no idea how easy or hard this edges are to fix, but it would be very cool if they were. If you need anything else, don't hesitate to contact me. Cheers, Alejandro ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Bug report of Oyster River Protocol made by macmanes lab.
Hello, my name is Ryoma Sato. I am a second-year master's student at the Graduate School of Bioresources and Environmental Sciences, Kyushu University in Japan. I have started the Oyster River Protocol, but I found a bug, so I will send you a report. Please check the following information. I would like you to tell me where is wrong. We are sorry for any inconvenience this may cause you, but we appreciate your cooperation. (orp_v2) [iceplant4561@at137 sampledata]$ ~/Oyster_River_Protocol/oyster.mk main STRAND=RF MEM=15 CPU=8 READ1=test.1.fq.gz READ2=test.2.fq.gz RUNOUT=test /bin/bash: activate: No such file or directory SALMON installed /bin/bash: activate: No such file or directory /bin/bash: activate: No such file or directory /bin/bash: activate: No such file or directory BUSCO installed /bin/bash: activate: No such file or directory /bin/bash: activate: No such file or directory SPADES installed /bin/bash: activate: No such file or directory TRINITY installed /bin/bash: activate: No such file or directory TRIMMOMATIC installed /bin/bash: activate: No such file or directory TRANSABYSS installed /bin/bash: activate: No such file or directory RCORRECTOR installed * Welcome to the Oyster River * * This is version 2.3.3 * /bin/bash: activate: No such file or directory ERROR, don't recognize parameter: --no_normalize_reads Please review usage info for accepted parameters. make: *** [/lustre7/home/iceplant4561/Oyster_River_Protocol/sampledata/assemblies/test.trinity.Trinity.fasta] Error 255 --- Kyushu University Graduate School Graduate School of Bioresource and Environmental Sciences Course of Agricultural Bioscience, Department of Bioresource Sciences Plant Production Physiology Laboratory, 2nd year master's student Ryoma Sato Mail: sato.ryoma@s.kyushu-u.ac.jp
Problems and Bugs: gnu-make 3.80 for windows bug report
Hi, I find a bug for creating make.exe in windowns, It can't get make.exe when compiling in windowns. I have resolved this bug as followed: edit the NMakefile , add "$(OUTDIR)/hash.obj" in the file, for example OBJS = \ $(OUTDIR)/ar.obj \ $(OUTDIR)/arscan.obj \ $(OUTDIR)/commands.obj \ $(OUTDIR)/default.obj \ $(OUTDIR)/dir.obj \ $(OUTDIR)/expand.obj \ $(OUTDIR)/file.obj \ $(OUTDIR)/function.obj \ $(OUTDIR)/getloadavg.obj \ $(OUTDIR)/getopt.obj \ $(OUTDIR)/getopt1.obj \ $(OUTDIR)/implicit.obj \ $(OUTDIR)/job.obj \ $(OUTDIR)/main.obj \ $(OUTDIR)/misc.obj \ $(OUTDIR)/read.obj \ $(OUTDIR)/remake.obj \ $(OUTDIR)/remote-stub.obj \ $(OUTDIR)/rule.obj \ $(OUTDIR)/signame.obj \ $(OUTDIR)/variable.obj \ $(OUTDIR)/version.obj \ $(OUTDIR)/vpath.obj \ $(OUTDIR)/glob.obj \ $(OUTDIR)/fnmatch.obj \ $(OUTDIR)/dirent.obj \ $(OUTDIR)/pathstuff.obj\ $(OUTDIR)/hash.obj the attatch file Best regards, yuanzhiyong in Beijing, China, 30-11-2005 NMakefile Description: Binary data ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.81: bug-report: function abspath works incorrectly on widows
> Date: Wed, 25 Jun 2008 20:19:39 +0400 > From: "Vitaly Murashev" <[EMAIL PROTECTED]> > > I found a bug in GNU Make 3.81 on MS Windows. So let me discuss it and > suggest a patch. Thanks. Your code is generally OK, but, unless I'm missing something, it has a few deficiencies: . It doesn't add an explicit drive letter to file names such as "/foo/bar", and generally treats such names incorrectly. . It doesn't produce fully qualified file names from drive-relative names such as "d:foo/bar". . It assumes Windows file names use only `/' as directory separator character, while in reality there could be `\' as well. Apologies if I misread your patch (I didn't really try to apply and use it). Thanks again for working on this. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.81: bug-report: function abspath works incorrectly on widows
On Wed, Jun 25, 2008 at 9:37 PM, Eli Zaretskii <[EMAIL PROTECTED]> wrote:
>> Date: Wed, 25 Jun 2008 20:19:39 +0400
>> From: "Vitaly Murashev" <[EMAIL PROTECTED]>
>>
>> I found a bug in GNU Make 3.81 on MS Windows. So let me discuss it and
>> suggest a patch.
>
> Thanks. Your code is generally OK, but, unless I'm missing something,
> it has a few deficiencies:
>
> . It doesn't add an explicit drive letter to file names such as
>"/foo/bar", and generally treats such names incorrectly.
You are right, and i suppose that the best way is to keep original GNU
Make behavior intact for this case.
E.g. "/foo/bar" must be treated as full qualified path even on MS Windows.
And my fix must affects only paths which are not prefixed with '/'.
>
> . It doesn't produce fully qualified file names from drive-relative
>names such as "d:foo/bar".
Not really. My patch produces the same output for "d:foo/bar"
and for "d:/foo/bar", the result is "d:/foo/bar"
>
> . It assumes Windows file names use only `/' as directory separator
>character, while in reality there could be `\' as well.
Yes, it does, but before my patch it assumes the same. And as i can
understand it is a common behavior for GNU Make. Even the 'current
directory'-variable internally uses '/' as a path separator. So i
don't like to fix this issue.
- - - - -
Please note, that the main goal of my patch is to fix code like this:
DIR_HERE = $(abspath $(dir $(lastword $(MAKEFILE_LIST
This code on MS Windows works incorrectly if it is invoked inside a
makefile which has been included from another makefile via full
qualified path to it. For example, we have two makefiles in the same
directory:
"d:\devl\test\makefile" and "d:\devl\test\test.mak"
'makefile' has the next code:
---
DIR_HERE = $(abspath $(dir $(lastword $(MAKEFILE_LIST
$(info makefile, DIR_HERE=$(DIR_HERE))
include $(DIR_HERE)/test.mak
---
'test.mak' has the next code:
---
$(info test.mak, DIR_HERE=$(DIR_HERE))
---
Output without my patch:
---
D:\devl\test>make
makefile, DIR_HERE=D:/devl/test
test.mak, DIR_HERE=D:/devl/test/D:/devl/test
make: *** No targets. Stop.
---
Output with my patch:
---
D:\devl\test>make_msvc.net2003.exe
makefile, DIR_HERE=D:/devl/test
test.mak, DIR_HERE=D:/devl/test
make_msvc.net2003.exe: *** No targets. Stop.
---
Reworked patch is in attachment.
Thanks.
--- function.c 2006-04-01 11:36:40.0 +0400
+++ function.c.fixed 2008-06-26 14:23:24.0 +0400
@@ -1883,13 +1883,18 @@
{
char *dest;
const char *start, *end, *apath_limit;
+ int prefix_offset = 1;
if (name[0] == '\0' || apath == NULL)
return NULL;
apath_limit = apath + GET_PATH_MAX;
- if (name[0] != '/')
+ if (name[0] != '/'
+#ifdef WINDOWS32
+ && name[1] != ':'
+#endif
+ )
{
/* It is unlikely we would make it until here but just to make sure. */
if (!starting_directory)
@@ -1901,8 +1906,22 @@
}
else
{
- apath[0] = '/';
- dest = apath + 1;
+#ifdef WINDOWS32
+ if(name[1] == ':')
+ {
+apath[0] = name[0];
+apath[1] = ':';
+apath[2] = '/';
+dest = apath + 3;
+prefix_offset = 3;
+name += 2;
+ }
+ else
+#endif
+ {
+apath[0] = '/';
+dest = apath + 1;
+ }
}
for (start = end = name; *start != '\0'; start = end)
@@ -1926,7 +1945,7 @@
else if (len == 2 && start[0] == '.' && start[1] == '.')
{
/* Back up to previous component, ignore if at root already. */
- if (dest > apath + 1)
+ if (dest > apath + prefix_offset)
while ((--dest)[-1] != '/');
}
else
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.81: bug-report: function abspath works incorrectly on widows
> Date: Thu, 26 Jun 2008 14:44:38 +0400 > From: "Vitaly Murashev" <[EMAIL PROTECTED]> > Cc: bug-make@gnu.org > > > . It doesn't add an explicit drive letter to file names such as > >"/foo/bar", and generally treats such names incorrectly. > > You are right, and i suppose that the best way is to keep original GNU > Make behavior intact for this case. > E.g. "/foo/bar" must be treated as full qualified path even on MS Windows. No, I think it should prefix the drive letter of the current disk. > > . It doesn't produce fully qualified file names from drive-relative > >names such as "d:foo/bar". > > Not really. My patch produces the same output for "d:foo/bar" > and for "d:/foo/bar", the result is "d:/foo/bar" Yes, but "d:foo/bar" and "d:/foo/bar" are not the same thing. The former refers to the current directory on drive d:, which could be different from the root. > > . It assumes Windows file names use only `/' as directory separator > >character, while in reality there could be `\' as well. > > Yes, it does, but before my patch it assumes the same. And as i can > understand it is a common behavior for GNU Make. No, GNU Make supports both types of slashes. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.81: bug-report: function abspath works incorrectly on widows
On Thu, Jun 26, 2008 at 10:43 PM, Eli Zaretskii <[EMAIL PROTECTED]> wrote: >> Date: Thu, 26 Jun 2008 14:44:38 +0400 >> From: "Vitaly Murashev" <[EMAIL PROTECTED]> >> Cc: bug-make@gnu.org >> >> > . It doesn't add an explicit drive letter to file names such as >> >"/foo/bar", and generally treats such names incorrectly. >> >> You are right, and i suppose that the best way is to keep original GNU >> Make behavior intact for this case. >> E.g. "/foo/bar" must be treated as full qualified path even on MS Windows. > > No, I think it should prefix the drive letter of the current disk. > >> > . It doesn't produce fully qualified file names from drive-relative >> >names such as "d:foo/bar". >> >> Not really. My patch produces the same output for "d:foo/bar" >> and for "d:/foo/bar", the result is "d:/foo/bar" > > Yes, but "d:foo/bar" and "d:/foo/bar" are not the same thing. The > former refers to the current directory on drive d:, which could be > different from the root. > >> > . It assumes Windows file names use only `/' as directory separator >> >character, while in reality there could be `\' as well. >> >> Yes, it does, but before my patch it assumes the same. And as i can >> understand it is a common behavior for GNU Make. > > No, GNU Make supports both types of slashes. > Hello Eli. Thanks for discussion. I reworked all discussed defects and want to suggest a new patch again. Also please note, that in the original (without suggested patch) GNU Make v.3.81 code like this: --- $(info $(abspath C:/../../../../..)) --- on MS Windows crashes make.exe with exception: "e:\test\make-3.81\Debug\make_msvc.net2003.exe": Interrupt/Exception caught (code = 0xc0fd, addr = 0x43fa59) It is occurs not always but when the count of ".."-elements in the above code exeeds the count of path-elements in current directory plus one. function.patch Description: Binary data ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: bug report : ERROR: dev-libs/lzo-2.06 failed (compile phase)
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
Re: bug report : ERROR: dev-libs/lzo-2.06 failed (compile phase)
On Thu, 2012-04-26 at 00:19 +, Christophe Poncy wrote: > 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 ). [...] > >>> Compiling source in > >>> /var/tmp/portage/dev-libs/lzo-2.06/work/lzo-2.06 ... > make -j7-l7 > make: l'option « -j » prend en argument un entier positif This is an error in the Portage build file for this package, or else in your local custom options. There must be a space between the two options "-j7" and "-l7"; they cannot be combined into a single option as above. This is not a problem with make itself, so this list is not the right place to ask about it. If you don't know what caused this error contact the Funtoo GNU/Linux support mailing lists for help. Good luck! ___ 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)
On Wed, 25 Apr 2012 20:30:41 -0400, Paul Smith wrote: On Thu, 2012-04-26 at 00:19 +, Christophe Poncy wrote: 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 ). [...] >>> Compiling source in >>> /var/tmp/portage/dev-libs/lzo-2.06/work/lzo-2.06 ... make -j7-l7 make: l'option « -j » prend en argument un entier positif This is an error in the Portage build file for this package, or else in your local custom options. There must be a space between the two options "-j7" and "-l7"; they cannot be combined into a single option as above. This is not a problem with make itself, so this list is not the right place to ask about it. If you don't know what caused this error contact the Funtoo GNU/Linux support mailing lists for help. Good luck! I had a space in my make.conf file (MAKEOPTS="-j7 -l7"). Well, everything seems working after a fresh install but I can't reproduce the bug so I didn't understood. Thankyou Martin and Paul for your advice, I wrote a little note on their forum... -christophe ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [Bug report] Make doesn't know $@ when referenced in the prerequisites
On Sun, 2017-03-19 at 01:51 +, Alejandro García Vallejo wrote: > bar: $(@:%r=foo%z) > @echo End > > foobaz: > @echo The > > """ > GNU Make Output: > End > > Make fails to read $@ (aka, it's empty). That's not a bug; that's defined behavior. From the GNU make manual: https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html > It’s very important that you recognize the limited scope in which > automatic variable values are available: they only have values within > the recipe. In particular, you cannot use them anywhere within the > target list of a rule; they have no value there and will expand to the > empty string. Also, they cannot be accessed directly within the > prerequisite list of a rule. A common mistake is attempting to use $@ > within the prerequisites list; this will not work. However, there is a > special feature of GNU make, secondary expansion (see Secondary > Expansion), which will allow automatic variable values to be used in > prerequisite lists. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug report of Oyster River Protocol made by macmanes lab.
> I found a bug If you have, then it's more likely in the documentation for this "Oyster River Project" than in the code of the Oyster River Project itself, let alone Gnu Make. > /bin/bash: activate: No such file or directory That looks like the kind of problem you get when one of Python's "virtualenv" things hasn't been activated. One of Google's first matches for Oyster River Project is https://github.com/macmanes-lab/Oyster_River_Protocol, which points to https://hackmd.io/@macmanes/SJhOQvkVm?type=view# which suggests that you might need to "Launch the conda environment" first. I won't be surprised if that doesn't help, because I'm afraid, Sato-san, you've come to the wrong place. No one here is likely to know anything about the Oyster River Project. I'm afraid it wasn't clear to me in a few minutes of googling where the right place might be. Good luck. From: Bug-make on behalf of Sato Ryoma Sent: Monday, January 10, 2022 15:53 To: bug-make@gnu.org Subject: Bug report of Oyster River Protocol made by macmanes lab. * EXTERNAL EMAIL * Hello, my name is Ryoma Sato. I am a second-year master's student at the Graduate School of Bioresources and Environmental Sciences, Kyushu University in Japan. I have started the Oyster River Protocol, but I found a bug, so I will send you a report. Please check the following information. I would like you to tell me where is wrong. We are sorry for any inconvenience this may cause you, but we appreciate your cooperation. (orp_v2) [iceplant4561@at137 sampledata]$ ~/Oyster_River_Protocol/oyster.mk main STRAND=RF MEM=15 CPU=8 READ1=test.1.fq.gz READ2=test.2.fq.gz RUNOUT=test /bin/bash: activate: No such file or directory SALMON installed /bin/bash: activate: No such file or directory /bin/bash: activate: No such file or directory /bin/bash: activate: No such file or directory BUSCO installed /bin/bash: activate: No such file or directory /bin/bash: activate: No such file or directory SPADES installed /bin/bash: activate: No such file or directory TRINITY installed /bin/bash: activate: No such file or directory TRIMMOMATIC installed /bin/bash: activate: No such file or directory TRANSABYSS installed /bin/bash: activate: No such file or directory RCORRECTOR installed * Welcome to the Oyster River * * This is version 2.3.3 * /bin/bash: activate: No such file or directory ERROR, don't recognize parameter: --no_normalize_reads Please review usage info for accepted parameters. make: *** [/lustre7/home/iceplant4561/Oyster_River_Protocol/sampledata/assemblies/test.trinity.Trinity.fasta] Error 255 --- Kyushu University Graduate School Graduate School of Bioresource and Environmental Sciences Course of Agricultural Bioscience, Department of Bioresource Sciences Plant Production Physiology Laboratory, 2nd year master's student Ryoma Sato Mail: sato.ryoma@s.kyushu-u.ac.jp
Bug report: Make cannot handle the word or path that contains space
Hi, Make cannot handle the word or path that contains space. Here's a sample: (tested on 3.81 and 3.82) -- INC=aa/hdr bb/hdr cc\ mgr/hdr INC_FLAG=$(addprefix -I,$(INC)) N=$(words $(INC)) all: test @echo INC_FLAG="$(INC_FLAG)" @echo N=$(N) test: $(INC) @echo INC="$(INC)" @echo INC="$^" %: ; -- Actual result: -- INC="aa/hdr bb/hdr cc\ mgr/hdr" INC="aa/hdr bb/hdr cc mgr/hdr" INC_FLAG="-Iaa/hdr -Ibb/hdr -Icc\ -Imgr/hdr" N=4 -- Expected result: -- INC="aa/hdr bb/hdr cc\ mgr/hdr" INC="aa/hdr bb/hdr cc\ mgr/hdr" INC_FLAG="-Iaa/hdr -Ibb/hdr -Icc\ mgr/hdr" N=3 -- Bug1: most internal function cannot deal with space that is escaped in the word. Bug2: $^ loses the back-slash. Best Regards Liang, Jian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
GNU Make bug report: broken dry-run functionality with sub-make invocations
Dear Devs, I stumbled upon a rather rare case where Make produces a false error with the --dry-run switch. I've attached a sample Makefile for reproduction. The output of make main_target with this file is the following: $ make main_target mkdir logs make external_target | tee logs/external_task.log make[1]: Entering directory '/tmp/21176961.tmpdir/bugrepro' This could be in a separate file somewhere make[1]: Leaving directory '/tmp/21176961.tmpdir/bugrepro' Nothing interesting there. But with the -n or --dry-run switch I get: $ make main_target -n mkdir logs make external_target | tee logs/external_task.log tee: logs/external_task.log: No such file or directory make[1]: Entering directory '/tmp/21176961.tmpdir/bugrepro' echo "This could be in a separate file somewhere" make[1]: Leaving directory '/tmp/21176961.tmpdir/bugrepro' make: *** [Makefile:11: main_target] Error 1 I get that the sub-make invocation gets executed with the switch passed to it as well, and that is correct functionality. But then the statement after the pipe also gets executed and throws an error about the missing log directory due to the prerequisite target not having been run. This causes false failures in release checks that use the --dry-run option of Make. This behavior is the same in both versions of GNU make that I have access to on the production system I'm using, 3.82 and 4.3 $ uname -r 3.10.0-693.21.1.el7.x86_64 $ make --version GNU Make 3.82 Built for x86_64-redhat-linux-gnu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. # (...) Loading other version $ make --version GNU Make 4.3 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. Makefile Description: Makefile
Re: Bug report: Make cannot handle the word or path that contains space
On Tue, 2013-01-29 at 14:42 +0100, Liang, Jian wrote: > Make cannot handle the word or path that contains space. You're right. The syntax of makefiles precludes this, and no version of make supports it. https://savannah.gnu.org/bugs/?712 ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU Make bug report: broken dry-run functionality with sub-make invocations
> the statement after the pipe also gets executed
Would you have Make parse the shell command, assuming that SHELL isn't eg
/usr/bin/perl, splitting off anything after | and maybe ; and && and, why not,
||, so it only dry-runs the part of the command that invoked $(MAKE)? The
current behavior is documented,
https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable
saying:
>> whenever a recipe line of a rule contains the variable MAKE, the flags ‘-t’,
>> ‘-n’ and ‘-q’ do not apply to that line
To put it another way: the Makefile needs to cope. Not doing the tee if the
directory doesn't exist would perhaps be most straightforward:
martind@sirius:~/tmp/ambrus-sumegi-2022-03-17$ diff -u Makefile{.orig,}
--- Makefile.orig 2022-03-17 11:13:46.000328340 -0700
+++ Makefile 2022-03-17 11:15:04.980482898 -0700
@@ -8,4 +8,4 @@
.PHONY: main_target
main_target: create_logdirs
- $(MAKE) external_target | tee logs/external_task.log
+ $(MAKE) external_target | { if test -d logs; then tee logs/external_task.log;
else cat; fi; }
martind@sirius:~/tmp/ambrus-sumegi-2022-03-17$
... though that means writing to the log with -n if the directory does exist,
which is perhaps undesirable. You could scrape the --dry-run flag out of
MAKEFLAGS, where it seems to get turned into n:
martind@sirius:~/tmp/ambrus-sumegi-2022-03-17$ diff -u Makefile{.orig,}
--- Makefile.orig 2022-03-17 11:13:46.000328340 -0700
+++ Makefile 2022-03-17 11:23:29.579910454 -0700
@@ -8,4 +8,4 @@
.PHONY: main_target
main_target: create_logdirs
- $(MAKE) external_target | tee logs/external_task.log
+ $(MAKE) external_target $(if $(findstring n,$(filter-out
--%,$(MAKEFLAGS))),,| tee logs/external_task.log)
martind@sirius:~/tmp/ambrus-sumegi-2022-03-17$
That coped with -nj --no-print-directory on the one version of Make that I
tested it with, but I don't know how portable that would prove.
Thank you for a nicely written up report with a minimal test case.
From: Bug-make on behalf of
Ambrus Sumegi
Sent: Thursday, March 17, 2022 08:59
To: bug-make@gnu.org
Subject: GNU Make bug report: broken dry-run functionality with sub-make
invocations
* EXTERNAL EMAIL *
Dear Devs,
I stumbled upon a rather rare case where Make produces a false error with the
--dry-run switch. I’ve attached a sample Makefile for reproduction.
The output of make main_target with this file is the following:
$ make main_target
mkdir logs
make external_target | tee logs/external_task.log
make[1]: Entering directory '/tmp/21176961.tmpdir/bugrepro'
This could be in a separate file somewhere
make[1]: Leaving directory '/tmp/21176961.tmpdir/bugrepro'
Nothing interesting there. But with the -n or --dry-run switch I get:
$ make main_target -n
mkdir logs
make external_target | tee logs/external_task.log
tee: logs/external_task.log: No such file or directory
make[1]: Entering directory '/tmp/21176961.tmpdir/bugrepro'
echo "This could be in a separate file somewhere"
make[1]: Leaving directory '/tmp/21176961.tmpdir/bugrepro'
make: *** [Makefile:11: main_target] Error 1
I get that the sub-make invocation gets executed with the switch passed to it
as well, and that is correct functionality. But then the statement after the
pipe also gets executed and throws an error about the missing log directory due
to the prerequisite target not having been run. This causes false failures in
release checks that use the --dry-run option of Make.
This behavior is the same in both versions of GNU make that I have access to on
the production system I’m using, 3.82 and 4.3
$ uname -r
3.10.0-693.21.1.el7.x86_64
$ make --version
GNU Make 3.82
Built for x86_64-redhat-linux-gnu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgnu.org%2Flicenses%2Fgpl.html&data=04%7C01%7CMartin.Dorey%40hitachivantara.com%7C4d9a04e9960e410518da08da083966b6%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637831339882701632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KpSFe0FVFzsYlsMTYPDwYOxRRfw26gNyhcXRaXwdesI%3D&reserved=0>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
# (…) Loading other version
$ make --version
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgnu.org%2Flicenses%2Fgpl.html&data=04%7C01%7CMartin.Dorey%40hitachivantara.com%7C4d9a04e9960e410518da08da083966b6%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637831339
Re: GNU Make bug report: broken dry-run functionality with sub-make invocations
On Thu, 2022-03-17 at 18:27 +, Martin Dorey wrote: > That coped with -nj --no-print-directory on the one version of Make > that I tested it with, but I don't know how portable that would > prove. Modern versions of make guarantee a canonical format of MAKEFLAGS such that you can parse them relatively easily, and with confidence. The details are in the manual I believe but the short is: * All options that have "short" variants with no arguments (for example --dry-run -> -n) are converted to the short variants and put into the first word, with no leading "-" * All other options are added after that. * Short options have a single dash prefix and if they have an argument it's attached to the option * Long options have a double-dash prefix (obviously) and if they have an argument it's attached to the option with an "=" * Options that have both short and long forms, prefer the short form. So, for -n, you can use: $(findstring n,$(word 1,$(MAKEFLAGS))) and it will expand to "n" if dry run is enabled (regardless of which form the option was given in), or empty if not. So, the OP could use something like this: DRYRUN = $(findstring n,$(word 1,$(MAKEFLAGS))) main_target: create_logdirs $(MAKE) external_target $(if $(DRYRUN),,| tee logs/external_task.log) There are other alternatives. For example, you could add "+" as a prefix to the recipe in the create_logdirs so that the directories are created even when "-n" is given. But ultimately Martin's comment is correct: this is not a bug in make and there's no possible way that make could do anything "better" than what it does. At some level, especially if you're writing recursive makefile environments, your recipes have to be written to be resilient to the possibility that make was invoked with "-n".
RE: GNU Make bug report: broken dry-run functionality with sub-make invocations
Thanks a lot for your suggestions, Martin and Paul. I understand the reasoning behind why Make cannot improve this behavior, and the conditional execution of tee that you both proposed looks like a concise and elegant solution to my problem. My only remaining concern is about the man page, which currently has this rather vague description of the switch in question: -n, --just-print, --dry-run, --recon Print the commands that would be executed, but do not execute them (except in certain circumstances). Perhaps the "(except in certain circumstances)" could be expanded to something like "If the line contains a call to $(MAKE), the entire line will still be executed, with the -n option passed to the sub-make instance. Be prepared for side effects of output redirection." -Original Message- From: Paul Smith Sent: 17 March 2022 20:08 To: Ambrus Sumegi Cc: bug-make@gnu.org Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make invocations On Thu, 2022-03-17 at 18:27 +, Martin Dorey wrote: > That coped with -nj --no-print-directory on the one version of Make > that I tested it with, but I don't know how portable that would prove. Modern versions of make guarantee a canonical format of MAKEFLAGS such that you can parse them relatively easily, and with confidence. The details are in the manual I believe but the short is: * All options that have "short" variants with no arguments (for example --dry-run -> -n) are converted to the short variants and put into the first word, with no leading "-" * All other options are added after that. * Short options have a single dash prefix and if they have an argument it's attached to the option * Long options have a double-dash prefix (obviously) and if they have an argument it's attached to the option with an "=" * Options that have both short and long forms, prefer the short form. So, for -n, you can use: $(findstring n,$(word 1,$(MAKEFLAGS))) and it will expand to "n" if dry run is enabled (regardless of which form the option was given in), or empty if not. So, the OP could use something like this: DRYRUN = $(findstring n,$(word 1,$(MAKEFLAGS))) main_target: create_logdirs $(MAKE) external_target $(if $(DRYRUN),,| tee logs/external_task.log) There are other alternatives. For example, you could add "+" as a prefix to the recipe in the create_logdirs so that the directories are created even when "-n" is given. But ultimately Martin's comment is correct: this is not a bug in make and there's no possible way that make could do anything "better" than what it does. At some level, especially if you're writing recursive makefile environments, your recipes have to be written to be resilient to the possibility that make was invoked with "-n". IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: GNU Make bug report: broken dry-run functionality with sub-make invocations
> On Mar 18, 2022, at 3:19 AM, Ambrus Sumegi wrote: > > Thanks a lot for your suggestions, Martin and Paul. I understand the > reasoning behind why Make cannot improve this behavior, and the conditional > execution of tee that you both proposed looks like a concise and elegant > solution to my problem. My only remaining concern is about the man page, > which currently has this rather vague description of the switch in question: > > -n, --just-print, --dry-run, --recon > Print the commands that would be executed, but do not execute > them (except in certain circumstances). > > Perhaps the "(except in certain circumstances)" could be expanded to > something like "If the line contains a call to $(MAKE), the entire line will > still be executed, with the -n option passed to the sub-make instance. Be > prepared for side effects of output redirection." +1 to this. Proposal: Print the commands that would be executed, but do not execute them in most cases. Note: If the line contains a call to $(MAKE), the entire line will still be executed, with the -n option passed to the sub-make instance that is run. Also, be prepared for side effects of output redirection. (If someone has a better way to write that last sentence, please do so.) It's a pretty important exception, so it should be explicitly described in the summary. --- David A. Wheeler
Re: GNU Make bug report: broken dry-run functionality with sub-make invocations
Maybe putting it in the form of a patch on the latest git source will help it over the finish line: diff --git a/doc/make.1 b/doc/make.1 index ec6f8a3b..4c258d68 100644 --- a/doc/make.1 +++ b/doc/make.1 @@ -222,8 +222,12 @@ With no argument, removes a previous load limit. Use the latest mtime between symlinks and target. .TP 0.5i \fB\-n\fR, \fB\-\-just\-print\fR, \fB\-\-dry\-run\fR, \fB\-\-recon\fR -Print the commands that would be executed, but do not execute them (except in -certain circumstances). +Print the commands that would be executed, but do not execute them in +most cases. +If the line contains a call to \fB$(MAKE)\fR, the entire line will still be +executed, with the \fB\-n\fR option passed to the sub-make instance that +is run. +Be prepared for side effects of output redirection. .TP 0.5i \fB\-o\fR \fIfile\fR, \fB\-\-old\-file\fR=\fIfile\fR, \fB\-\-assume\-old\fR=\fIfile\fR Do not remake the file From: David A. Wheeler Sent: Friday, March 18, 2022 09:08 To: Ambrus Sumegi Cc: psm...@gnu.org ; Martin Dorey ; bug-make@gnu.org Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make invocations * EXTERNAL EMAIL * > On Mar 18, 2022, at 3:19 AM, Ambrus Sumegi wrote: > > Thanks a lot for your suggestions, Martin and Paul. I understand the > reasoning behind why Make cannot improve this behavior, and the conditional > execution of tee that you both proposed looks like a concise and elegant > solution to my problem. My only remaining concern is about the man page, > which currently has this rather vague description of the switch in question: > > -n, --just-print, --dry-run, --recon > Print the commands that would be executed, but do not execute > them (except in certain circumstances). > > Perhaps the "(except in certain circumstances)" could be expanded to > something like "If the line contains a call to $(MAKE), the entire line will > still be executed, with the -n option passed to the sub-make instance. Be > prepared for side effects of output redirection." +1 to this. Proposal: Print the commands that would be executed, but do not execute them in most cases. Note: If the line contains a call to $(MAKE), the entire line will still be executed, with the -n option passed to the sub-make instance that is run. Also, be prepared for side effects of output redirection. (If someone has a better way to write that last sentence, please do so.) It's a pretty important exception, so it should be explicitly described in the summary. --- David A. Wheeler
Re: GNU Make bug report: broken dry-run functionality with sub-make invocations
On Fri, 2022-03-18 at 17:48 +, Martin Dorey wrote: > Maybe putting it in the form of a patch on the latest git source will > help it over the finish line: I'm OK with adding some short text about this into the man page. As David mentions it may be important enough to do that since command being run by make even when the user gives "-n" could give unexpected or even unpleasant consequences. However, in general I want to be clear that the man page is not, and is not intended to be, user documentation. It's a reference page. The man page is intended for people who ALREADY KNOW how to run make and write makefiles, but need to quickly remind themselves of some syntax that might have slipped their mind, and they don't want to have to search the manual for it. make and makefiles are entirely too complex a topic to be addressed in a man page. If you want to learn about how something works, not just remind yourself how to use it, you need to be reading the user manual not the man page. Everything should be documented in full and understandable detail in the user manual. https://www.gnu.org/software/make/manual/html_node/index.html
Re: GNU Make bug report: broken dry-run functionality with sub-make invocations
Paul Smith wrote: I'm OK with adding some short text about this into the man page. As David mentions it may be important enough to do that since command being run by make even when the user gives "-n" could give unexpected or even unpleasant consequences. The most unpleasant consequences of using 'make -n' and pressing Ctrl-C, is for me that 'make' hangs real good. Seemingly waiting for nothing (?); a "dead-lock". It's this 5 year old bug I believe: https://savannah.gnu.org/bugs/?51237 Using his version: https://github.com/mbuilov/gnumake-windows/blob/master/gnumake-4.3.exe as 'make -n ...' on a large complex Makefile, I've seldom seen a complete hang. But could take some time to stop. Just my 0.02 €. -- --gv
Re: GNU Make bug report: broken dry-run functionality with sub-make invocations
> On Mar 18, 2022, at 2:03 PM, Paul Smith wrote: > > On Fri, 2022-03-18 at 17:48 +, Martin Dorey wrote: >> Maybe putting it in the form of a patch on the latest git source will >> help it over the finish line: > > I'm OK with adding some short text about this into the man page. As > David mentions it may be important enough to do that since command > being run by make even when the user gives "-n" could give unexpected > or even unpleasant consequences. It's also a potential security problem. Someone who runs "make -n" and expects *nothing* to be run (other than make) will NOT get what they expect. Hinting, in the man page, that some statements *are* run seems appropriate... and if we can be specific without a lot of text, even better. > However, in general I want to be clear that the man page is not, and is > not intended to be, user documentation. It's a reference page. I agree. But adding 1-2 sentences seems reasonable. --- David A. Wheeler
RE: GNU Make bug report: broken dry-run functionality with sub-make invocations
For the record, I've thought of a sort-of-solution to the "would you have Make
parse the shell command" question over the weekend. If the sub-make was called
through a function rather than a variable, the whole issue could be a lot more
contained. Having $(make, "") as the canonical
form of invoking other Make instances could guarantee that no other program
gets called when the -n switch is used. This way any elaborate multi-line
command containing $(MAKE) could more or less be fixed with a sed command to
completely eliminate this problem class.
Of course, one could still do something like $(make, $(shell
("some_reckless_command")), but it would be more obvious, and Make could output
an explicit warning about a shell being called together with the sub-make
invocation, or even refuse to execute said shell call. Since on Fri 18/03/2022
20:14, psm...@gnu.org<mailto:psm...@gnu.org> pointed out that this is also a
potential security problem, a future release could deprecate the $(MAKE)
variable and switch to the function-based invocation, with shell calls disabled
within it by default for the sake of that extra bit of security.
From: Martin Dorey
Sent: 17 March 2022 19:27
To: Ambrus Sumegi ; bug-make@gnu.org
Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make
invocations
> the statement after the pipe also gets executed
Would you have Make parse the shell command, assuming that SHELL isn't eg
/usr/bin/perl, splitting off anything after | and maybe ; and && and, why not,
||, so it only dry-runs the part of the command that invoked $(MAKE)? The
current behavior is documented,
https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable
saying:
>> whenever a recipe line of a rule contains the variable MAKE, the flags '-t',
>> '-n' and '-q' do not apply to that line
To put it another way: the Makefile needs to cope. Not doing the tee if the
directory doesn't exist would perhaps be most straightforward:
martind@sirius:~/tmp/ambrus-sumegi-2022-03-17$ diff -u Makefile{.orig,}
--- Makefile.orig 2022-03-17 11:13:46.000328340 -0700
+++ Makefile 2022-03-17 11:15:04.980482898 -0700
@@ -8,4 +8,4 @@
.PHONY: main_target
main_target: create_logdirs
- $(MAKE) external_target | tee logs/external_task.log
+ $(MAKE) external_target | { if test -d logs; then tee logs/external_task.log;
else cat; fi; }
martind@sirius:~/tmp/ambrus-sumegi-2022-03-17$
... though that means writing to the log with -n if the directory does exist,
which is perhaps undesirable. You could scrape the --dry-run flag out of
MAKEFLAGS, where it seems to get turned into n:
martind@sirius:~/tmp/ambrus-sumegi-2022-03-17$ diff -u Makefile{.orig,}
--- Makefile.orig 2022-03-17 11:13:46.000328340 -0700
+++ Makefile 2022-03-17 11:23:29.579910454 -0700
@@ -8,4 +8,4 @@
.PHONY: main_target
main_target: create_logdirs
- $(MAKE) external_target | tee logs/external_task.log
+ $(MAKE) external_target $(if $(findstring n,$(filter-out
--%,$(MAKEFLAGS))),,| tee logs/external_task.log)
martind@sirius:~/tmp/ambrus-sumegi-2022-03-17$
That coped with -nj --no-print-directory on the one version of Make that I
tested it with, but I don't know how portable that would prove.
Thank you for a nicely written up report with a minimal test case.
From: Bug-make
mailto:bug-make-bounces+martin.dorey=hds@gnu.org>>
on behalf of Ambrus Sumegi
mailto:ambrus.sum...@arm.com>>
Sent: Thursday, March 17, 2022 08:59
To: bug-make@gnu.org<mailto:bug-make@gnu.org>
mailto:bug-make@gnu.org>>
Subject: GNU Make bug report: broken dry-run functionality with sub-make
invocations
* EXTERNAL EMAIL *
Dear Devs,
I stumbled upon a rather rare case where Make produces a false error with the
--dry-run switch. I've attached a sample Makefile for reproduction.
The output of make main_target with this file is the following:
$ make main_target
mkdir logs
make external_target | tee logs/external_task.log
make[1]: Entering directory '/tmp/21176961.tmpdir/bugrepro'
This could be in a separate file somewhere
make[1]: Leaving directory '/tmp/21176961.tmpdir/bugrepro'
Nothing interesting there. But with the -n or --dry-run switch I get:
$ make main_target -n
mkdir logs
make external_target | tee logs/external_task.log
tee: logs/external_task.log: No such file or directory
make[1]: Entering directory '/tmp/21176961.tmpdir/bugrepro'
echo "This could be in a separate file somewhere"
make[1]: Leaving directory '/tmp/21176961.tmpdir/bugrepro'
make: *** [Makefile:11: main_target] Error 1
I get that the sub-make invocation gets executed with the switch passed to it
as well, and that is correct functionality. But then the statement after the
pipe also gets executed and throw
Re: GNU Make bug report: broken dry-run functionality with sub-make invocations
On Mon, 2022-03-21 at 09:34 +, Ambrus Sumegi wrote: > For the record, I’ve thought of a sort-of-solution to the “would you > have Make parse the shell command” question over the weekend. If the > sub-make was called through a function rather than a variable, the > whole issue could be a lot more contained. Having $(make, “ passed to sub-make>”) as the canonical form of invoking other Make > instances could guarantee that no other program gets called when the > -n switch is used. This way any elaborate multi-line command > containing $(MAKE) could more or less be fixed with a sed command to > completely eliminate this problem class. I don't see how this would work. The command you wanted to run was: $(MAKE) external_target | tee logs/external_task.log You wanted to pipe the output of the make command to another command. How does putting make in a function allow this to happen? > Of course, one could still do something like $(make, $(shell > (“some_reckless_command”)), but it would be more obvious, and Make > could output an explicit warning about a shell being called together > with the sub-make invocation, or even refuse to execute said shell > call. Since on Fri 18/03/2022 20:14, psm...@gnu.org pointed out that > this is also a potential security problem, a future release could > deprecate the $(MAKE) variable and switch to the function-based > invocation, with shell calls disabled within it by default for the > sake of that extra bit of security. It's simply not possible to make this change. People want to do all kinds of complicated things before or after or instead of invoking the sub-make, so the full power of the shell needs to be available. If you wanted to simply run a make command with no surrounding shell operations, then running: $(MAKE) ... all by itself _already_ does exactly what you want. It's only when you need to add extra operations into the same recipe line that you run into problems with "-n", and that's exactly the place where using a make function instead won't work.
Re: GNU Make bug report: broken dry-run functionality with sub-make invocations
(We generally prefer to use inline replies on the GNU lists, rather than top-posted replies, thanks) On Mon, 2022-03-21 at 13:22 +, Ambrus Sumegi wrote: > If the invocation is a function, i.e., `$(make,"external_target") | > tee logs/external_task.log` then Make knows exactly where the call to > the sub-make ends without having to parse a shell command. So, when > running with the -n switch, it can simply print "make external_target > | tee logs/external_task.log" and proceed to show the output of `make > external_target -n` So if someone runs make -n it would be OK if only the make was invoked, without actually sending any of the output to the tee (because clearly the tee would not be invoked)? That idea seems just as fraught, of not moreso, as the original behavior. What if your recipe looked like this: test -f afile || $(MAKE) -C foo If you change your makefile to use the putative function like this: test -f afile || $(make -C foo) Are you saying that if "make -n" is invoked this recipe will ALWAYS run the sub-make, regardless of whether the "afile" file exists or not? If you check makefiles out in the world you'll see that many times the recipe lines that are used to invoke sub-makes are complex with lots of additional shell operations in the same recipe line. IMO a facility that reached into the middle of all that scripting and plucked out the sub-make by itself and ran it without any of that surrounding context, when make -n was given, would be at least as dangerous as what we have now.
RE: GNU Make bug report: broken dry-run functionality with sub-make invocations
If the invocation is a function, i.e., `$(make,"external_target") | tee logs/external_task.log` then Make knows exactly where the call to the sub-make ends without having to parse a shell command. So, when running with the -n switch, it can simply print "make external_target | tee logs/external_task.log" and proceed to show the output of `make external_target -n` -Original Message- From: Paul Smith Sent: 21 March 2022 14:18 To: Ambrus Sumegi ; bug-make@gnu.org Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make invocations On Mon, 2022-03-21 at 09:34 +, Ambrus Sumegi wrote: > For the record, I’ve thought of a sort-of-solution to the “would you > have Make parse the shell command” question over the weekend. If the > sub-make was called through a function rather than a variable, the > whole issue could be a lot more contained. Having $(make, “ passed to sub-make>”) as the canonical form of invoking other Make > instances could guarantee that no other program gets called when the > -n switch is used. This way any elaborate multi-line command > containing $(MAKE) could more or less be fixed with a sed command to > completely eliminate this problem class. I don't see how this would work. The command you wanted to run was: $(MAKE) external_target | tee logs/external_task.log You wanted to pipe the output of the make command to another command. How does putting make in a function allow this to happen? > Of course, one could still do something like $(make, $(shell > (“some_reckless_command”)), but it would be more obvious, and Make > could output an explicit warning about a shell being called together > with the sub-make invocation, or even refuse to execute said shell > call. Since on Fri 18/03/2022 20:14, psm...@gnu.org pointed out that > this is also a potential security problem, a future release could > deprecate the $(MAKE) variable and switch to the function-based > invocation, with shell calls disabled within it by default for the > sake of that extra bit of security. It's simply not possible to make this change. People want to do all kinds of complicated things before or after or instead of invoking the sub-make, so the full power of the shell needs to be available. If you wanted to simply run a make command with no surrounding shell operations, then running: $(MAKE) ... all by itself _already_ does exactly what you want. It's only when you need to add extra operations into the same recipe line that you run into problems with "-n", and that's exactly the place where using a make function instead won't work. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: GNU Make bug report: broken dry-run functionality with sub-make invocations
Ambrus Sumegi (21 March 2022 14:22) wrote: > If the invocation is a function, i.e., `$(make,"external_target") | > tee logs/external_task.log` then Make knows exactly where the call to > the sub-make ends without having to parse a shell command. So, when > running with the -n switch, it can simply print "make external_target > | tee logs/external_task.log" and proceed to show the output of `make > external_target -n` However, that doesn't help cases like subdirs:; find sub/ -type f -name Makefile | \ sed -e 's!/Makefile!!' | grep . | \ while read dir; do $(MAKE) -C $$dir; done where the failure to run the rest of the command makes the call to $(MAKE) never happen; and replacing the last line with while read dir; do $(make -C $$dir); done or similar won't save you. Fixing one use-case while breaking all others is no solution, Eddy.
Bug report made anonymously should be assigned to my username on Savannah for receiving updates on it
Hi, I've reported this bug anonymously : https://savannah.gnu.org/bugs/index.php?62200 and would like to receive updates/comments on it by mail on my Savannah account, I don't know if the bug report could be assigned to me or the "posted by" field could be updated to my username on Savannah (AkechiShiro ). Thanks for any help regarding this matter. -- Kind regards, Lahfa Samy
Re: Bug report made anonymously should be assigned to my username on Savannah for receiving updates on it
On Fri, 2022-03-18 at 21:12 +, Lahfa Samy wrote: > I've reported this bug anonymously : > https://savannah.gnu.org/bugs/index.php?62200 and would like to > receive updates/comments on it by mail on my Savannah account, I > don't know if the bug report could be assigned to me or the "posted > by" field could be updated to my username on Savannah (AkechiShiro > ). Unfortunately I'm not aware of an way to reset the submitter of the bug. However, you can add yourself to the CC list to receive any updates made to it: look at the bottom of the bug to find the Mail Notification Carbon-Copy List and add yourself.
