[bug #18617] Better debugging facilities: tracing rule invocation.
Follow-up Comment #5, bug #18617 (project make): I would like to draw the attention of everyone in this thread to http://bashdb.sourceforge.net/remake/ Remake - GNU Make with comprehensible tracing and a debugger I find it an invaluable enhancement to make when debugging complex makefiles full of generated code. Give it a try: you won't look back once you've discovered how much easier life is when you can single-step through the source of a makefile, set breakpoints, inspect variables and see the return values from called functions. Stefano: It doesn't tell which the implicit rule is, are you sure? The trace shows Trying implicit prerequisite `assert.cxx'. Found an implicit rule for `/home/stefano/src/reilabs/flash2sip/contrib/src/ptlib_2.2.1/lib/obj_linux_x86_r/assert.o'. Therefore the implicit rule it is referring to must be of the form %.o: %.cxx mustn't it? ___ Reply to this item at: http://savannah.gnu.org/bugs/?18617 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: 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
RE: Makefile doesnt stop for non zero error codes
Murali Krishna wrote on 25 June 2008 07:38: Hi I am working in a makefile issue where the makefile doesn't stop compilation even after it encounters the error in the cpp file. The make continues with next rule even though the earlier rule gives the non zero exit status. What could be the possible cause for this scenario? There's a bug on line 278 of your makefile. You just need to fix it and everything will work fine. . . . Nahh, seriously, an example or some details would be nice. Did you use -k when invoking make? Are the command-lines prefixed with - to suppress errors? Are you mistaken about whether the earlier rule actually does return non-zero status? It's pretty hard to diagnose a problem when the only information you give is It doesn't work - why?! Can you show us an example, with the relevant lines of your makefile and the output you see in your shell when building? 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
RE: Reg Make build on LINUX
A, Sravanthi wrote on 23 May 2008 12:14: Hi team, Iam trying to build my application using make on Linux server. But my build doesn't stop after first error. I tried -S options but doesn't seems to help. The top-level makefile might be invoking the sub-makes using - at the start of the commandline to suppress errors? See the Errors in Commands section of the man/info page. 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 #23273] Please include xkcd easteregg
Follow-up Comment #1, bug #23273 (project make): +1 funny. ___ Reply to this item at: http://savannah.gnu.org/bugs/?23273 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: eval and if-blocks incompatible on i386-pc-linux-gnu
Paul Smith wrote: On Wed, 2008-04-23 at 17:11 +0200, Arthur Carlson wrote: $ make SWITCH=on a makefile:10: *** missing `endif'. Stop. This is a bug in GNU make 3.80. You should upgrade to 3.81. Interesting factoid: This bug is[*] also fixed (or perhaps was never exposed) in remake[**], which is still based on the 3.80 sources. So if you wanted a working make that could handle the syntax shown, but don't want any of the backwardly-incompatible changes in behaviour that were introduced in 3.81 relative to 3.80[***], installing remake would be a suitable workaround. cheers, DaveK [*] - At least, as far as I have seen, the symptoms do not manifest; I have not been through the source code to try and understand for absolutely certain why not. [**] - http://bashdb.sourceforge.net/remake/ [***] - I forget exactly what the incompatible changes were, but I'm fairly sure there were one or two. They're listed in the NEWS file. They may not matter to you for your purposes, in which case this whole email is moot. -- 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 #22434] Consider a dependancy as target file and try to make the file
Follow-up Comment #3, bug #22434 (project make): Your testcase is way too complex to be convenient - it would be more helpful if you could make a self-contained example, rather than requiring people to install Hg and then clone your repository and then autoconf a makefile and only /then/ be able to even /start/ looking at the problem. So this is only a guess, but it sounds like you've missed or misread the part of the manual that explains that all dependencies are always supposed to be prerequisites, and if you just want a goal as a dependency that doesn't make a target file of the same name, you have to list it as a .PHONY target. Are you simply missing a .PHONY declaration to tell make that Pokme isn't the name of a real output file? ___ Reply to this item at: http://savannah.gnu.org/bugs/?22434 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #20501] MAKEFLAGS += -rR doesn't turn off default suffix rules, variables
Follow-up Comment #2, bug #20501 (project make): As far as I can see this is not a bug, this is make performing exactly as described in the manual. MAKEFLAGS is not a live way of controlling a running make's behaviour, it is used solely for the purpose of passing down to a recursive invocation of make; that is why you find they work when you run a subsequent call from the makefile, by which I think you mean a recursive submake invocation. Please review the make documentation, 5.7.3 Communicating Options to a Sub-`make', and verify whether you really have a bug here or not. http://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html#Options_002fRecursion cheers, DaveK ___ Reply to this item at: http://savannah.gnu.org/bugs/?20501 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #20501] MAKEFLAGS += -rR doesn't turn off default suffix rules, variables
Follow-up Comment #4, bug #20501 (project make): I'm sorry, I missed that! I think you're right; it is a bug. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20501 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Typo in GNU make book
On 23 January 2008 17:01, Lorenzo CIAMPOLINI wrote: Hi, Dunno if the address is correct, I have the pdf of GNU make by Stallman, McGrath, Smith, the July 2002 edition, I have a feeling taht at page 75 there is a bug in the define PROGRAM_template, instead of $$($(1)_OBJ) should be $$($(1)_OBJS) That seems to already be fixed in the make documentation at source: http://www.gnu.org/software/make/manual/html_node/Eval-Function.html#Eval-Function If you'd like an updated pdf, you can download one from http://www.gnu.org/software/make/manual/make.pdf 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
RE: make multiple buffer overflow
On 06 December 2007 05:09, laurent gaffie wrote: Application: Make = 3.81 Web Site: http://savannah.gnu.org/projects/make/ http://www.gnu.org/software/make/ Platform: Unix Bug:multiple buffer overflow Proof of concept example : make `perl -e 'printAx4096'` //*** make -f `perl -e 'printAx4096'` make -j `perl -e 'printAx4096'` make -i `perl -e 'printAx4096'` make -l `perl -e 'printAx4096'` *** depending the case , you'll need to change the value , for a couple of more A , playing by hundred should be good to make sure you trigger it I couldn't reproduce any of these, on either Linux or Cygwin, on 3.80 or 3.81 (although I didn't try absolutely every possible combination there). I get lots of stat: AA[...]: File name too long and No rule to make target `A[..]' messages instead. [EMAIL PROTECTED]:~# gdb make GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. Is it possible that debian's distro has a customised version of make? Did you build make from CVS sources or tarballs? I see you've got no stack backtrace in your debug output, if you did build your own you'd get symbol info. (gdb) run `perl -e 'printAx4296'`//my GCC version have a protection for stack smashing then 200 chars more , and we trigger it Hmm, perhaps the stack smashing protection is generating a false positive? I guess this implies that you /are/ building make from sources, yes? Starting program: /usr/bin/make `perl -e 'printAx4296'` (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1209637200 (LWP 1246)] make: stat: AAA A.AA That's the kind of message I see from make... Program received signal SIGSEGV, Segmentation fault. ... but I don't get a SEGV. Can you try it again without stack protection? 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 #21661] Make expands command-line variable defnitions after/during every command invocation
Follow-up Comment #1, bug #21661 (project make): As far as I can see, this is the expected and as-intended behaviour. Try make 'var:=$(warning hello)' instead, and refresh your memory on the difference between immediate and deferred expansion. ___ Reply to this item at: http://savannah.gnu.org/bugs/?21661 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: make 3.81: showing time differences
On 27 October 2007 22:21, Bruno Haible wrote: Hi, With GNU make 3.81 the following warnings were seen: make[5]: Warning: File `.deps/test-xvasprintf.Po' has modification time 4.8e+02 s in the future make[2]: Warning: File `Makefile' has modification time 1.1e+02 s in the future make[1]: Warning: File `Makefile' has modification time 95 s in the future The notation 4.8e+02 s is a quite obfuscated way to express 4 minutes. Well, yes, since it's actually 8 minutes :-) 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
RE: prorex-1.3 make bug
On 19 October 2007 11:52, Jon Grant wrote: Hi, [...] /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: prorex.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC prorex.o: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [libprorex.so] Error 1 That isn't an issue with Make. There is a linker error, re-read the message you quoted above and you ill see it tells you what the problem is and how to fix it! Always read things thoughtful before posting to mailing lists ;) If that doesnt fix it, contact the libprorex developers who provided you with the source code. It could also be worth asking about on the binutils list. I *think* (but am not sure) that it's to do with linking mixed -fPIC and non-fPIC code, perhaps libprorex.so wasn't compiled with it? Or perhaps it's something from libgcc that needs multilibbing against fPIC. Binutils list ought to be able to help. 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
RE: Switching from CVS to GIT
On 18 October 2007 07:13, Jim Meyering wrote: Paul Smith [EMAIL PROTECTED] wrote: I'm considering switching from CVS to another form of SCM. Currently, ... It seems like GIT is where the mindshare is these days, plus a number of the other autotools projects have already migrated (or are in the middle of migrating) to GIT, so that's what I'd go with. ... Congratulations! :-) I don't really know what the current state-of-the-art is WRT GIT on non-POSIX systems, so... please give me your opinions on this change. I heard it was usable months ago, but less efficient than on Unix-based systems. http://cygwin.com/acronyms/#YSHFRTT! 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
[PATCH] Extend --debug with option to trace parsing.
Hi! It can be really tricky debugging a complex makefile that's full of function calls and evals, so here's a patch that adds lots of debugging output from the parser. You get to see exactly what the parser's seeing and what it thinks it's doing about it. 2007-09-02 Dave Korn [EMAIL PROTECTED] * doc/make.texi: Documented new 'p' option letter to '--debug='. * debug.h (DB_PARSER): New debug flag bit. * main.c (decode_debug_flags): Let 'p' set DB_PARSER in db_level. * read.c (eval): Added a whole lot of debug under DB_PARSER. cheers, DaveK -- Can't think of a witty .sigline today make-debug-parser-patch.diff Description: Binary data ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [PATCH] Implement verbatim export.
On 21 August 2007 13:39, Paul Smith wrote: On Mon, 2007-08-20 at 18:59 +0100, Dave Korn wrote: As discussed last week, and ported to CVS head from our own internal build over the weekend, here's a patch that implements verbatim export of makefile variables to subprocesses. This is particularly handy for anything with a dollar sign in it! I'll have to think about this; it seems like a lot of change for something that very few people have ever asked for. Also, there are at least two ways to share variable values with other instances of make that I don't think have the issue you're having: one is to pass the value via the command line instead of through the environment (where you can use $(value ...)) and the other is to put it into a makefile that is included by the different instances of make. What do you think about those? Both valid, but I think they're less convenient. With the first method, you either have to enumerate all the functions explicitly, or follow a naming convention that lets you grep them out of .VARIABLES and automatically add them to the submake command line. You're also likely to run into shell quoting complications. I would have said that big command lines are a problem in themselves, but then again I think on most systems there's a limit on the total of (commandline length + environment size) anyway, so that's no different. The second one works too, but in my case I didn't want to hard-code an explicit full or relative path to the library file, because I don't want stuff lower in the hierarchy to know about what's going on further up. For my money, the ideal solution was for the top-level makefile to include the library, and for it to then be available to everything below. I expected export to do this for me and found it not in accordance with my particular definition of least surprise when the exported functions ended up in the submake but were mangled! After all, when you use export in a shell, what you see in the sub-shell is exactly what you exported. It's subjective of course, but speaking as someone who does an awful lot of maintenance programming myself, I think the patch isn't really a lot of change. I added a stanza in snap_deps that follows an existing pattern and is obviously correct. I added a third state to export_all_vars and ensured I fixed every reference. I added or verbatim to the condition that detects the export directive and a simple ternary operator to the assignments. Most of this is mechanical. The only tricky bit is the evaluation of do_verbose I think, and I think it's right the way I've written it. I'm pretty sure that in the absence of the verbatim keyword, the existing behaviour is exactly preserved, and I don't think the syntax is terribly likely to clash with anyone's existing makefiles (I know you *can* have variable names like 'vebatimSPACEfoo', but I bet it doesn't happen much in practice). It's a nice feature, it fits very well with what make already does and makes it more orthogonal and complete, it facilitates good architecture and style, and it matches the intuitive expectations that anyone from a posix background will have about what it means to export a variable. I'd already written the code for my own internal purposes so it was no trouble to offer it back upstream - and it's always nice to avoid forks, in general. Any of the lurkers round here have opinions? 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
[PATCH] Implement verbatim export.
Hi Paul, and whoever else may be listening. As discussed last week, and ported to CVS head from our own internal build over the weekend, here's a patch that implements verbatim export of makefile variables to subprocesses. This is particularly handy for anything with a dollar sign in it! ChangeLog, full documentation and even a testcase included! Buy one, get two free! Hurry, this offer cannot last! goes for a little lie down * file.c (snap_deps): Also check for .EXPORT_ALL_VARIABLES_VERBATIM pseudo-target, and set export_all_variables accordingly. * read.c (eval): Accept 'verbatim' keyword as well as 'export' and set either export_all_variables or the new variable's export type accordingly. Use correct enumerated type to clear export_all_variables when unexporting. * variable.c (export_all_variables): Change type to enum export_all. (target_environment): Handle new enumerated values for variable_export and export_all_variables. Export variables without expanding values when verbatim export requested. * variable.h (enum export_all): Enumeration for export_all_variables, as it is now tri-state rather than boolean. (struct variable): Add new enumerated value to enum variable_export for verbatim export, and extend size of bitfield by one bit so all new values still fit. (export_all_variables): Change type of declaration to enum export_all. * doc/make.texi: Extend Variables/Recursion node to document verbatim export. Document new .EXPORT_ALL_VARIABLES_VERBATIM pseudo-target. * tests/scripts/features/verbatim: New testcase for verbatim export. cheers, DaveK -- Can't think of a witty .sigline today verbatim-export-patch-full-ported.diff Description: Binary data verbatim Description: Binary data ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: gnumake[1]: execvp: /bin/sh: The parameter or environmentlists are too long
On 15 August 2007 04:59, Paul Smith wrote: On Sun, 2007-08-12 at 22:31 -0400, Kothanda_Sathya wrote: How it looks on our GNUmakefile, if sources specified within the limit around 450, this error occurs otherwise it reports error the parameter or environment list are too long. The maximum size of the environment for a new process (which includes not only the environment variables but also the command line arguments) is a limit set by the operating system (the kernel). It has nothing to do with GNU make and there is no possible way that GNU make can increase that limit: it's not modifiable from user space (in fact typically it can't be modified except by recompiling the kernel). I came up with an idea that solves some cases of this problem: http://lists.gnu.org/archive/html/help-make/2007-03/msg00011.html Could dust off the patch and rework it against current cvs if anyone cares. 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
RE: Single-suffix rules broken?
On 12 August 2007 15:07, Ludovic Courtes wrote: Am I missing something The fact that you already sent this yesterday and it already got answered two hours before you resent it? Did the first answer fall in your spam bin maybe? 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
RE: problem with GNU make configure
On 04 August 2007 00:08, Christopher Faylor wrote: On Sat, Aug 04, 2007 at 01:08:54AM +0300, Eli Zaretskii wrote: Date: Fri, 3 Aug 2007 14:55:15 -0700 (PDT) From: [EMAIL PROTECTED] oops, here is the attached console capture It's much better to send this as plain text (you can capture it with `tee' or even by copying and pasting the contents into your mailer). My crystal ball says that somehow the configure script god DOS-style CR-LF line endings, which make Cygwin Bash barf. That's right. That is exactly the problem. Use u2d to fix it. You mean 'd2u'. This is not a GNU make problem. Nik, did you use winzip or some similar windows gui to unpack the make sources? If you did, don't, they often 'helpfully' convert lineendings; use the cygwin command-line tar. The other possibility is that you've installed cygwin with dos-mode line endings when you used setup.exe. That can be switched back by rerunning setup.exe. If you need more help, come and post over on the cygwin mailing list and we'll sort it out there. See the list page for archive, (un)subscribe and posting details. http://cygwin.com/cygwin/lists.html#cygwin 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
RE: $(and) and $(or) not working
On 16 May 2007 16:22, Noel Yap wrote: I'm using the following: yapn:[EMAIL PROTECTED]:~/proj/aoeu make --version GNU Make 3.81beta4 Note the beta tag. And the $(and) and $(or) functions always return empty. Has anyone else experienced this? Probably means they weren't yet implemented at the time the beta was released. To find out for sure, try using the --warn-undefined-variables option; if the built-ins aren't implemented, those will just look like variable references to empty vars. 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
RE: GNU Make: A Program for Directing Recompilation, GNU make Version 3.81, April 2006 Documentation
On 06 May 2007 14:50, Bob wrote: Some documentation issues for GNU Make: A Program for Directing Recompilation, GNU make Version 3.81, April 2006. 1) On page 34, Section 4.8 Special Built-in Target Names, there's repeated text. The text under .SUFFIXES is also the second paragraph under .SECONDEXPANSION. So it is! 2) On page 87, Section 8.8 The eval Function, there's a problem with the code example if make clean is issued, because the $(ALL_OBJS) variable in the rm command under clean, won't be initialized (and I'm curious how you'd do it). ALL_OBJS is /always/ initialised. The foreach always runs, the ALL_OBJS+= statements generated by the call PROGRAM_template are always eval'd, where do you see a problem? 3) On page 106, Section 10.3 Variables Used by Implicit Rules, there's repeated text. The CO entry is repeated twice, once after CC and another time after CXX. Yep, it sure is. 4) A general recommendation, when lists are given, such as on page 106, Section 10.3, and the order of the entries is arbitrary, sort them in alphabetic sequence. Well, they aren't entirely arbitrary, they're roughly grouped into similar functionality: (binutils AR, AS) (compiler CC, CXX, CPP, FC) (rcs CO, GET) (parsing LEX, YACC, LINT) (couple more less-used complers M2C, PC) (docs build tools MAKEINFO, TEX, TEXI2DVI, WEAVE, CWEAVE, TANGLE, CTANGLE) (misc RM) ..with CO doubled and slightly misplaced. In that particular case, straight alpha order would scatter related things all over the place. I'd suggest that for this one, we move the CO entry so it's just before GET (kill the dup), and perhaps bring M2C and PC back up to join the other language compilers. Attached patch does just that, and fixes 1) as well. cheers, DaveK -- Can't think of a witty .sigline today docs-patch.diff Description: Binary data ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16389] Defaults for Objective-C
Follow-up Comment #5, bug #16389 (project make): why not just add the rules into your makefile if you need them? Not easy to do if you're talking about a large number of projects. I do realize this means that any makefile that uses objective-C needs to be changed, but the same is true for any number of other languages that make doesn't provide default rules for. Obj-C is provided by GNU CC. It makes sense for GNU Make to provide builtin support for the entire family of languages supported by GNU CC. Further, even if we do change this for the next release of GNU make that won't be out for some months, then it will be many months more before that version is considered wide spread That's a problem for end users and distro creators, not for the GNU Make maintainer; they can all deal with it however they wish, but adding the patch gives them the option. And finally, of course, requiring default rules just means makefiles are even more tightly tied to GNU make I don't think this is a real problem either. Anyone who is building ObjC is almost certainly using Gnu Make. After all, this would be a reason to remove all the string functions and other GNU-specific features, but in fact, it is not GNU Make's purpose to be a subset of all other make implementations; it intends to be standardised enough to correctly process non-GNU makefiles, while adding enhancements useful to support the technical and political goals of the GNU project. I vote for acceptance. ___ Reply to this item at: http://savannah.gnu.org/bugs/?16389 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Ping Re: @file response file support for make
On 18 March 2007 20:49, Joseph S. Myers wrote: Ping. Any views on this patch or the principle of this feature http://lists.gnu.org/archive/html/bug-make/2006-09/msg8.html? I think it's eminently sensible. The @-file is increasingly a standard convention. 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
RE: BUG while running the make file
On 07 February 2007 18:11, Eli Zaretskii wrote: Date: Wed, 7 Feb 2007 11:51:56 -0500 From: Raheja, Himanshu [EMAIL PROTECTED] gcc -I.. -I. -I./include -I./common -D_FILE_OFFSET_BITS=64 -I/usr/include -g -W -Wall -Werror -Wno-unused -g -O2 -D_FILE_OFFSET_BITS=64 -g -W -Wall -Werror -Wno-unused -DHAVE_CONFIG_H -c ./common/linksupport.c -o linksupport.o /tmp/ccsjrIuh.s: Assembler messages: /tmp/ccsjrIuh.s:1368: Error: Incorrect register `%rax' used with `l' suffix /tmp/ccsjrIuh.s:1617: Error: Incorrect register `%rax' used with `l' suffix make[1]: *** [linksupport.lo] Error 1 This has nothing to do with Make: the error message comes from the assembler invoked by the compiler (GCC). So either your compiler is misconfigured, or maybe linksupport.c has some invalid inline assembly in it. Or perhaps more likely, there's a version mismatch with the binutils. Himanshu, are you using a recent gcc (4.x.x) with an old (2.16 or less) binutils? Or maybe an old gcc with a more recent binutils? 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
RE: BUG while running the make file
On 07 February 2007 18:44, Raheja, Himanshu wrote: Hi Folks, I was able to resolve that issue by googling: When I ran ./configure CFLAGS=-m32 LDFLAGS=-m32 And after that make install was working fine. But I am not sure why this was happening. Probably because your compiler is a recent one, and defaults to compiling 64-bit code, but your binutils are slightly out of date and have bugs trying to assemble the 64-bit code. The -m32 flag that you have found out to use makes sure the compiler still generates 32-bit code, which the binutils do not have any problem with. So you end up with a 32-bit executable. (It might be possible to upgrade your binutils and get the build to work for 64 bits, and the resulting executable might run faster, but it's not something to try unless you were confident with upgrading packages and knew how to revert to the old one if something went wrong.) 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
RE: BUG while running the make file
On 07 February 2007 21:02, Raheja, Himanshu wrote: Kindly help and suggest what could be done. You'll have to contact a mailing list relating to LPRng for this kind of in-depth advice; it's way out of our scope here. Sorry! 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
RE: not able start Dansguardian service
On 30 January 2007 17:06, Martin Dorey wrote: From the evidence you have provided, it looks like you have a pre-installed version of dansguardian that isn't working and that you've successfully configured but not tried to build or install a version of dansguardian from source. If I were you, I'd be looking in /var/log/messages or /var/log/syslog for any error message produced when you try to start the dansguardian service, then googling for help with that. This mailing list won't be able to help you. This mailing list is for bugs in the make program. There's no evidence of such a bug here. Perhaps all that Prakash is missing is to run make all; make install in the source directory after having run the configure command. If not, Prakash, you will need to find a mailing list for questions about dansguardian. 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 #18872] problem colon after drive letter in prerequisite
Follow-up Comment #3, bug #18872 (project make): I'm fairly confident that cygwin's GCC will only generate dos-style paths in the output dependency files if you pass it in dos-style paths on the commandline or in #include statements. If it were to do so for any other reason, that would indeed be a bug, and I'd be very glad to see a testcase posted to the cygwin mailing list. cheers, DaveK ___ Reply to this item at: http://savannah.gnu.org/bugs/?18872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Bug: make igores options, switches and targets
On 19 January 2007 11:57, James Coleman wrote: Is your make aliased to something else or is it a script ? And if it is invoked from sh is the same make invoked? Could there be any environment difference causing the problem? which make sh -c 'which make' ls -al `which make` alias |grep make sh -c 'alias |grep make' Looking for things like that might be worthwhile. You can use the 'which' shell builtin, it tells you at once and saves you having to search it out: /artimi/software/firmware $ type make make is /artimi/tools/cygwin/bin/make /artimi/software/firmware $ type type type is a shell builtin /artimi/software/firmware $ type cls cls is aliased to `cmd /c cls' /artimi/software/firmware $ sh -c 'type make' make is /artimi/tools/cygwin/bin/make /artimi/software/firmware $ sh -c 'type type' type is a shell builtin /artimi/software/firmware $ sh -c 'type cls' sh: line 0: type: cls: not found /artimi/software/firmware $ 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
RE: [bug #18517] Compilation error in find_directory() in dir.c onWindows platforms
On 13 December 2006 16:58, Martin Dorey wrote: p[-1] = '\0'; What makes you think this is a compilation error? Do you have a compiler error message for us? Did you miss the fact that p is const? 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
RE: problems with Net-PCap
On 04 December 2006 23:35, sofia wrote: Hello, I'm trying to install the packages Net-Pcap0.14 but it's impossible to do make,it reports: /usr/bin/ld: /usr/local/lib/libpcap.a(pcap-linux.o): no se puede usar la reubicación R_X86_64_32 contra `a local symbol' cuando se hace un objeto compartido; recompile con -fPIC One cannot use the relocation R_X86_64_32 against a local symbol when one is making a segmented object; recompile with -fPIC. /usr/local/lib/libpcap.a: no se puede leer símbolos: Valor erróneo collect2: ld returned 1 exit status make: *** [blib/arch/auto/Net/Pcap/Pcap.so] Error 1 I have tried with -fPIC and with several options(-k,-i,-B..) but it always happens the same. No hay problema con 'make'; el problema se queda entre los binutils. Pregunté a la lista [EMAIL PROTECTED]. 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 #18335] Addition of $(math ...) functions
Follow-up Comment #2, bug #18335 (project make): Oh, BTW, I would suggest ... $(math $(VAL)+($(FOO)/4)) ... that a lisp-like (non-reverse Polish) notation might be more consistent with the general style of make here: $(plus $(VAL),$(divide $(FOO),4)) cheers, DaveK ___ Reply to this item at: http://savannah.gnu.org/bugs/?18335 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Cygwin make thinks a statement can be neither true nor false....
-Original Message- From: Paul Smith On Behalf Of Paul D. Smith Sent: 20 April 2004 19:35 To: Dave Korn %% Dave Korn http://cygwin.com/acronyms/#PCYMTNQREAIYR writes: dk [ This is getting off topic for the cygwin list, I'll leave it here for now but I'm happy to remove cygwin if folks would like. Nobody's complained yet, but me likewise: if anyone wants this thread off the cygwin list, just ask. [ about --warn-undefined-variables ] The problem is that in many makefiles you tend to get a lot of false positives. For example, many makefiles leave certain variables to be set by the user, like CPPFLAGS or CFLAGS. If you do that in your makefiles, and the user has no reason to set them, then you'll get lots o' warnings. You can work around this with various GNU make-specific fanciness, but most developers don't bother. dk BTW, did I discuss the difficulty in determining whether a dk variable is undefined or empty? Not with me... to tell the difference you have to use the $(origin ...) function and test if the value is undefined. Annoying but... possible! :). Hmm. So might there be call for a variant of --warn-undefined-variables that only warns about those for which $(origin ..) returns undefined? That way makefiles could supply empty-but-overrideable definitions of CFLAGS etc, and everyone's happy... I think? dk ifne ($(VARIABLE), anything) So, this is a syntax error: it should be ifneq. D'oh and double d'oh! That has to be the worst cognitive blind spot I've experienced in years. I've spent ages and ages reading through the info docs in the past couple of days and *every*single*time* I've misread the conditional as ifne rather than ifneq. Boy, do I look stupid! Make parses makefiles line-by-line, and it categorizes each line as one of three things (four things for GNU make): [...snip...] If none of the above applies (and in GNU make, if it's not a preprocessor line), then make doesn't have any idea what the heck the line is, so it says: missing separator which means, I couldn't find any of the tokens that allow me to classify this line as one of the three (or four) things I know about, so ... eh? BINGO! The $(SMALL_CURRENCY_UNIT) finally drops! I think 90% of the problems I have grokking makefile parsing is that I've been working on the assumption that it had a full parser, with a lexer and a stream of tokens and something vaguely bison/yacc like. For instance, I was about to ask, given that you can have a colon as a char in a variable name, how does make know whether VAR:=stuff means to assign 'stuff' to VAR immediately, or do a deferred assign of 'stuff' to 'VAR:'. Your explanation suddenly makes lots of things clear, and I think it should probably be added to the documentation. Thank you SO much! dk I'd just like to point out that it isn't only $shell that is dk affected: $error and $warning are also affected. I also notice dk that it works fine if you escape the semicolon: Right. This is a parser bug, pure and simple. Except, not so simple because the parser has to do the proper matching to realize that the ; is part of a variable or function content. As gross as the syntax is, the make parser has to be equally quirky in order to handle it :-/. Yeh. I wonder if it would be possible to build a proper parser, using lexx/yacc/bison/whatever. But I guess it would be very hard to guarantee that it behaved in the same way as the original one for backward compatibility purposes. cheers, DaveK -- Can't think of a witty .sigline today ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
RE: Cygwin make thinks a statement can be neither true nor false....
-Original Message- From: cygwin-owner On Behalf Of Ross Ridge Sent: 20 April 2004 02:41 [ Cc'd to the gmake bug reporting list; the actual bug report is at the end of this post, and is not what the topic of this thread was originally about. ] Possibly a bug in make, as I'd expect it to complain about an undefined function named error:. I would've expected it to complain about a bad substition reference, ie. it's missing an =. Or at least do anything, rather than nothing! Similar constructs are also silently ignored: $(foo This isn't a valid make function) $(bar Neither is this) Since foo and bar aren't functions supported by GNU Make these are just simple variable references. Eg: foo This isn't a valid make function=one bar Neither is this=two test: echo $(foo This isn't a valid make function) echo $(bar Neither is this) Eeeurgh. It even warns about this kind of nonsense in 'info make': ---snip!--- A variable name may be any sequence of characters not containing `:', `#', `=', or leading or trailing whitespace. However, variable names containing characters other than letters, numbers, and underscores should be avoided, as they may be given special meanings in the future, and with some shells they cannot be passed through the environment to a sub-`make' (*note Communicating Variables to a Sub-`make': Variables/Recursion.). ---snip!--- Great. So for the benefit of providing a feature that is virtually impossible to safely and correctly use (chars in variable names that aren't allowed in shell variables) the authors of make have created a syntax that is so ambiguous it defies error detection and reporting. Wahey. Considering the close conceptual relationship between shell variables and make variables, and the way they get exported and imported to each other, it just seems like a mistake to try and pretend they're decoupled to such an extent they could be incompatibly named. Anyway, I've found what seems to be a real bug in make (or perhaps in the make docs): here's a quote from the item Communicating Options to a Sub-`make' (under Node: Options/Recursion) in 'info make' ---snip!--- Likewise variables defined on the command line are passed to the sub-`make' through `MAKEFLAGS'. Words in the value of `MAKEFLAGS' that contain `=', `make' treats as variable definitions just as if they appeared on the command line. *Note Overriding Variables: Overriding. ---snip!--- Oh no it doesn't: neither for variables defined on the initial make command line, nor for variables passed to a recursive submake. Here's my sample makefile: ---snip!--- $(warning : MAKEFLAGS are $(MAKEFLAGS)) $(warning : MAKEOVERRIDES are $(MAKEOVERRIDES)) .PHONY: all silly force all: $(MAKE) silly FOO=1 BAR=2 BAZ=3 $(MAKE) silly BILL=1 BEN=2 silly: force echo Make silly. force: ; echo force ---snip!--- and here's what happens when I test it: ---snip!--- [EMAIL PROTECTED] /davek/test/mk-test/test3 ls -al total 1 drwxr-xr-x+ 2 dk Domain U0 Apr 20 12:40 . drwxr-xr-x+ 5 dk Domain U0 Apr 20 12:40 .. -rw-r--r--1 dk Domain U 240 Apr 20 12:47 makefile [EMAIL PROTECTED] /davek/test/mk-test/test3 make makefile:2: : MAKEFLAGS are --unix makefile:3: : MAKEOVERRIDES are make silly FOO=1 BAR=2 BAZ=3 make[1]: Entering directory `/davek/test/mk-test/test3' makefile:2: : MAKEFLAGS are --unix -w makefile:3: : MAKEOVERRIDES are BAZ=3 BAR=2 FOO=1 echo force force echo Make silly. Make silly. make[1]: Leaving directory `/davek/test/mk-test/test3' make silly BILL=1 BEN=2 make[1]: Entering directory `/davek/test/mk-test/test3' makefile:2: : MAKEFLAGS are --unix -w makefile:3: : MAKEOVERRIDES are BEN=2 BILL=1 echo force force echo Make silly. Make silly. make[1]: Leaving directory `/davek/test/mk-test/test3' [EMAIL PROTECTED] /davek/test/mk-test/test3 make DOES_IT_WORK=NO_NOT_AT_ALL makefile:2: : MAKEFLAGS are --unix makefile:3: : MAKEOVERRIDES are DOES_IT_WORK=NO_NOT_AT_ALL make silly FOO=1 BAR=2 BAZ=3 make[1]: Entering directory `/davek/test/mk-test/test3' makefile:2: : MAKEFLAGS are --unix -w makefile:3: : MAKEOVERRIDES are BAZ=3 BAR=2 FOO=1 DOES_IT_WORK=NO_NOT_AT_ALL echo force force echo Make silly. Make silly. make[1]: Leaving directory `/davek/test/mk-test/test3' make silly BILL=1 BEN=2 make[1]: Entering directory `/davek/test/mk-test/test3' makefile:2: : MAKEFLAGS are --unix -w makefile:3: : MAKEOVERRIDES are BEN=2 BILL=1 DOES_IT_WORK=NO_NOT_AT_ALL echo force force echo Make silly. Make silly. make[1]: Leaving directory `/davek/test/mk-test/test3' [EMAIL PROTECTED] /davek/test/mk-test/test3 ---snip!--- As you can see, they still end up in $MAKEOVERRIDES, so there's a simple and practical workaround, but either the docs or the program behaviour are
RE: Cygwin make thinks a statement can be neither true nor false....
-Original Message- From: Paul Smith On Behalf Of Paul D. Smith Sent: 20 April 2004 16:44 [ This is getting off topic for the cygwin list, and unless I've managed to spot any *real* bugs yet, it's not very OT for the bug-make list either; if we want to carry on further we should perhaps take it to private mail or to the help-make list, though I'm not subbed to any of the make lists. ] %% Dave Korn [EMAIL PROTECTED] writes: I would've expected it to complain about a bad substition reference, ie. it's missing an =. dk Or at least do anything, rather than nothing! If you enable --warn-undefined-variables then you'll get a warning. Ah, thanks! That's such a good option I think I'm about to alias it right into all my make commands. BTW, did I discuss the difficulty in determining whether a variable is undefined or empty? That may not seem like a meaningful concept, but I want to know whether my makefile was correctly invoked but the variable definition was empty, such as make -f makefile FOO= all or whether the invocation was incorrect by forgetting to specify a value for FOO, make -f makefile all At the moment, ifndef FOO succeeds equally in both cases. Well, this has been true of every version of make since make was invented 30+ years ago, not to mention required by the POSIX standard, so... a little late to worry about it now :). Heh, I know. But any changes that could make less damn obfuscatory than it already is would be great. It's really in the error of diagnostics and reporting that make has serious problems, presumably at least some of which could be fixed without altering its behaviour? I mean, look at this: (I'm not going to call it a bug _just_ yet, because things that seem utterly unreasonable to me *keep* on turning out to be the expected and desired behaviour!) --- [EMAIL PROTECTED] /davek/test/mk-test/test5 ls makefile1 makefile2 [EMAIL PROTECTED] /davek/test/mk-test/test5 cat makefile1 $(warning one one) ifne ($(VARIABLE), anything) $(warning two two) BUILDDIR_EXTRA=-boot else $(warning three three) endif all: echo So what's that all about then eh ? [EMAIL PROTECTED] /davek/test/mk-test/test5 cat makefile2 $(warning one one) ifeq ($(VARIABLE), anything) $(warning two two) BUILDDIR_EXTRA=-boot else $(warning three three) endif all: echo So what's that all about then eh ? [EMAIL PROTECTED] /davek/test/mk-test/test5 make -f makefile1 makefile1:2: one one makefile1:3: *** missing separator. Stop. [EMAIL PROTECTED] /davek/test/mk-test/test5 make -f makefile1 VARIABLE=anything makefile1:2: one one makefile1:3: *** missing separator. Stop. [EMAIL PROTECTED] /davek/test/mk-test/test5 make -f makefile1 VARIABLE=anything_else makefile1:2: one one makefile1:3: *** missing separator. Stop. [EMAIL PROTECTED] /davek/test/mk-test/test5 make -f makefile2 makefile2:2: one one makefile2:7: three three echo So what's that all about then eh ? So what's that all about then eh ? [EMAIL PROTECTED] /davek/test/mk-test/test5 make -f makefile2 VARIABLE=anything makefile2:2: one one makefile2:4: two two echo So what's that all about then eh ? So what's that all about then eh ? [EMAIL PROTECTED] /davek/test/mk-test/test5 make -f makefile2 VARIABLE=anything_else makefile2:2: one one makefile2:7: three three echo So what's that all about then eh ? So what's that all about then eh ? [EMAIL PROTECTED] /davek/test/mk-test/test5 --- Now where's the sense in that? How can it be that the semantics of the conditional operator affects the validity of the otherwise-identical syntax? Every time make gives me that same old error message, I just want to scream at it WHAT THE HELL KIND OF SEPARATOR ARE YOU EVEN TALKING ABOUT, YOU DELUSIONAL MANIAC? dk Considering the close conceptual relationship between shell dk variables and make variables, and the way they get exported and dk imported to each other, it just seems like a mistake to try and dk pretend they're decoupled to such an extent they could be dk incompatibly named. I don't agree that there is a close conceptual relationship. In fact, I think it's very important to not view make variables that way. Well, IMO there is a confused and unclear relationship. In some ways they're tightly coupled, and in other ways the links are broken. Make does _NOT_ export every variable into the environment. I never said that; I said that the two do not map to clearly distinct concepts, but to overlapping sets. Make treats the environment variable space and its internal variable space as two distinct entities, and makefile writers are well advised to consider them that way as well. When make starts up it imports all of the environment variables as make variables, yes. And, the user can request that certain variables be exported from the make variable space into sub-processes
