Re: [bug] (un)escaping problem in the makefile database output
On Mon, 2007-06-04 at 11:19 +0800, Agent Zhang wrote: Or is it indeed intentional by design and the database is not supposed to be in strictly-valid makefile notation anyway? I'm not sure, so I think it may be wise to ask here first before firing off a bug report to Savannah. It's certainly not intentionally one way or the other: the output from -p is intended as a debugging tool for users. I don't believe it was ever intended to be used as valid makefile input into another program (or even back into GNU make itself). And there's certainly no intent to make it an _invalid_ makefile either. I expect the lack of quoting for the # is nothing more or less than oversight or laziness (and I mean laziness in the good, Larry Wall way :-)). Feel free to file an enhancement request on Savannah to have this addressed. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
My website...
Is currently unavailable due to a difference of opinion with my ISP as to whether I've already given them their money or not :-/. Hopefully this will be resolved shortly and the site will be back up again. Sorry for the inconvenience *sigh*. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: gnu make problem
On Thu, 2007-05-17 at 11:17 +0530, chandan wrote: I am trying to build Microsoft visual c++ programs at the command line using GNU MAKE. The msdn library says that If you have a project that you build from the command line with a make file, then the Visual Studio development environment will not recognize your project. This is because visual studio has its own MAKEFILE PROJECT WIZARD. Isn’t there any way to build it at the command line using gnu make? If yes, please brief me about it. I have been able to build turbo c++ programs using gnu make very easily. I am using make-3.75 version. I would be really very grateful if you can help me in this regard. Please choose only ONE of the mailing lists to ask your question. It's annoying to spam all the lists with the same question. If your question is only relevant on a Windows platform (as this one is) then the right list is [EMAIL PROTECTED] Thanks. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Make fails on glibc build
On Thu, 2007-05-17 at 10:16 +0200, Alexander Kahl wrote: Hi, I was building glibc today and make (newest cvs version) failed with make: file.c:147: enter_file: Assertion `*name != '\0'' failed. make: *** [all] Aborted Interesting. Of course, the CVS versions of GNU make are not production ready, but I'd like to reproduce this bug. Please provide more information, such as the version of glibc you're trying to build, the OS type/version you're building on, what configure commands you used, etc. If you'd be willing, you could also run make under the debugger and get a stack trace where the assert is taken. Thanks! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: $(and) and $(or) not working
On Wed, 2007-05-16 at 11:21 -0400, Noel Yap wrote: I'm using the following: yapn:[EMAIL PROTECTED]:~/proj/aoeu make --version GNU Make 3.81beta4 I've seen a number of messages stating that people are using 3.81beta4; why are people still using a beta version over a year after the final version was released (3.81 was released on 01 Apr 2006)? Did it get shipped with some distribution or software package? If so you should file a bug and request an update to the released version. Anyway, as others have pointed out, the and and or functions weren't implemented in beta4. PS. Please choose one of bug-make or help-make, but not both. Cheers! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 33 make check failures on Ubuntu Linux
On Sat, 2007-04-28 at 15:22 +0100, Jon Grant wrote: Could this message below be updated to remind that make update is needed to download the po files? That message is generated from the standard gettext build environment, that is provided by the gettext package. It's not part of the GNU make source at all. And, of course, we can't add it into gettext because the make update step is make specific (well, some other tools use this method as well but it's not standard). But if you follow the directions in the README.cvs file, you should not have any problems... -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Build warnings in CVS make 3.81.90
On Sat, 2007-04-28 at 15:26 +0100, Jon Grant wrote: A wider query relating to these warnings is that since make 3.81 is released now, could we change make to use const's instead of #define'd values, and inline functions instead of #define macro expressions? No... well, at least not inline. While I have made the decision to no longer support pre-ANSI, KR-only compilers as of 3.82, I'm still requiring ANSI C89 clean code, and inline is not valid C89. Const integers are legal of course, but I don't know that they really add much clarity. file.c: In function 'file_timestamp_cons': file.c:765: warning: comparison of unsigned expression 0 is always false file.c:766: warning: comparison between signed and unsigned file.c:766: warning: comparison of unsigned expression 0 is always false file.c:769: warning: comparison of unsigned expression 0 is always false I haven't looked at these in a while, but the last time I looked this warning was actually an integral part of the implementation of these macros. In other words, if you fixed the warnings the macros wouldn't work as designed anymore. You might look in the ChangeLog. Paul Eggert provided these macros so we'd need to discuss any changes with him. function.c: In function 'func_lastword': function.c:696: warning: 'p' may be used uninitialized in this function Oops, that's a bug. Fixed. function.c: In function 'func_shell': function.c:1597: warning: variable 'error_prefix' might be clobbered by 'longjmp' or 'vfork' function.c:1589: warning: argument 'o' might be clobbered by 'longjmp' or 'vfork' These have been around forever and I don't know how to fix them. If you do, please let me know. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 33 make check failures on Ubuntu Linux
On Sun, 2007-04-22 at 14:49 +0100, Jon Grant wrote: I just ran make check and got 33 failures. I'm running make 3.81, on a 6 month old Ubuntu Linux install. They are all the same issue, the extra space. Not sure where the extra space comes from, is anyone else seeing this? Please be sure that your LC_ALL and/or LANG variables are set to C before running make check. I thought that I had modified this inside the Perl scripts that drive the tests, but apparently I didn't get it right; there was a bug report about it (this has been fixed in CVS now though). If that fixes the problem, I'm interested to see what locale you were using before... it seems odd to me that someone would make a translation that changes the string . Stop. to . Stop. (if you look at the fatal() function in misc.c you'll see where this string comes from). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.80 works, make 3.81 only works with SHELL=
On Wed, 2007-04-25 at 23:05 -0400, Marty Leisner wrote: There's a line SHELL=/bin/sh in the makefile... This is illegal. Make is not the shell; it does not strip quotes like the shell does. Quoting is not harmless in make. These two variables: FOO = A BAR = A are very different; FOO is set to the single character string A, while BAR is set to the three character string A. For SHELL, if you set it to /bin/sh then make will invoke /bin/sh to run commands, which will work. If you set SHELL to /bin/sh, then make will try to invoke the command /bin/sh (including the quotes), which of course doesn't exist. Now, in reality neither make 3.80 or 3.81 does precisely the right thing here; however, 3.81 is closer to what should happen: the command should fail to run at all unless you have created the program /bin/sh on your system (including the quotes). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Possible bug with make 3.81 beta 4
On Thu, 2007-04-12 at 15:57 +0200, Oriol Franquesa Cortés wrote: Makefile archive runs on version 3.80 but not in 3.1 beta4 version. I think that is a possible bug. You should try the released version of GNU make 3.81. It was released over a year ago so there is no reason to be using a beta version any longer. I send you all project because you can fix better the possible fix. I'm sorry but we can't debug complete build systems on this list. If you're having a problem you must provide a description of the problem, along with at least the command line you entered and the error message you received, plus, if possible, a small makefile that reproduces the problem. You should also examine the NEWS file that comes with GNU make; any known backward compatibility issues will be listed there. Make sure your makefile is not being affected by one of those. Alternatively, you might contact a mailing list or help forum for the zeos project and see if they have any thoughts about it. -- --- 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://lists.gnu.org/mailman/listinfo/bug-make
Re: make + cmake = test failure
On Wed, 2007-03-21 at 16:17 -0500, Matthew Woehlke wrote: Any guesses? No guesses here. I can't think of any changes in make 3.81, offhand, that would impact the environment used by the child process. I think before we can debug this we need you or someone to examine the cmake failure and try to figure out what is causing it. If we had some idea of what that test is testing and why it's not working we might be able to understand what is different. You can also try things like: running the test under strace in both success and failure modes; printing the environment when you run the test in both success and failure modes; etc. to try to figure out what might be different. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: @file response file support for make
On Mon, 2007-03-19 at 15:36 +, Joseph S. Myers wrote: Now done. Great; thanks! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: @file response file support for make
On Thu, 2006-09-07 at 20:49 +, Joseph S. Myers wrote: There is a de facto standard solution to this problem, which is that a command line argument of the form @file causes arguments to be read from file (a response file) if it exists. (If file doesn't exist, @file is taken literally as an ordinary command-line argument.) This feature is supported by GCC and GNU binutils, for example; I think it originated on Windows, but it is useful everywhere with any command line limit. This seems like a very useful additional feature. Can you please add this patch to the Savannah project for GNU make, so we don't lose track of it? https://savannah.gnu.org/patch/?func=additemgroup=make Thanks for your work on this! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: False warning about a circular dependency
On Mon, 2007-03-05 at 18:41 +0100, Johannes Hölzl wrote: VPATH := ../dir/ all: a .SECONDARY: a: b b @echo compile ../dir/b: $ mkdir ../dir $ touch ../dir/b $ make -f test.make make: Circular a - b dependency dropped. compile Of course a depends on b, but why depends b on a? When only one b is on the a line, the message isn't shown, when the .SECONDARY: is missing it isn't shown and when the b file is placed under ./dir the message is also not shown. I can confirm this on my Linux box. It's even stranger if you look at the debug output, since make appears to try to build b right after it considers all, without first considering a (according to the output). Please file a bug against GNU make at the Savannah project site so we can track this issue: https://savannah.gnu.org/projects/make/ If you don't have a Savannah account and you file this bug anonymously, be sure to add yourself to the CC list so you'll get updated when a fix is available. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: not linking when using -j option
On Mon, 2007-03-05 at 12:39 +0100, Depner, Simon wrote: when im using this command: make -j 7 BUILD_SPEC=PPC32gnu DEBUG_MODE=1 TRACE=1 clean all the make is not linking, so diden't get any out-files. Sorry, but there's not nearly enough information here to allow us to help you. Further, this mailing list is for bugs in the make program; it seems to me that there's probably something wrong with your makefile or environment, rather than a bug in 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 Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: build breaks
On Wed, 2007-02-28 at 07:36 +, Guyeng Gankhuyag wrote: the build breaks whenever I include the ext2_fs.h header into C file as simple as following: This mailing list is for bugs in the GNU make program. Your problem has nothing to do with GNU make, so it's not appropriate for this mailing list. You need to find a mailing list or forum related to Linux programming to answer your question. One short answer is that the headers in the linux/* and asm/* directories are kernel headers and are not intended to be included directly into user-space programs, except in very controlled ways. I really believe what you guys do is a crap. Well, I guess we're even then since I really believe that your attitude is a crap. Good luck finding help. Cheers! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: multi-line commands with quoted SHELL
On Thu, 2007-02-22 at 19:00 +0100, Petr Machata wrote: There is a bug tracked in Red Hat bugzilla http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219409 The problem is best demonstrated by this Makefile snippet: all:;@echo e\ cho With this make invocation, it works as intended: $ make 'SHELL=/bin/sh' echo But when the SHELL variable contains quotes, it fails: $ make 'SHELL=/bin/sh' e /bin/sh: line 1: cho: command not found make: *** [all] Error 127 The problem is that when SHELL contains quotations etc., /bin/sh is invoked, and whole command is passed through that. But the outer shell then destroys the backslash-newline sequences. The solution is to singly-quote these. The attached patch against make 3.81 does this. Hm. Personally I think this is an error and should not be handled, even as it is currently handled. If the user sets: SHELL = /bin/sh in my opinion make should try to invoke the program '/bin/sh' (including the quotes). Having a quoted value of SHELL invoked using /bin/sh -c (with another level of indirectness) is, in my opinion, wrong. I can only assume this behavior of trying to manage quotes in the value of SHELL is due to some bizarre behavior of some long-forgotten make that GNU make tried to duplicate. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: glibc build process slowness
On Wed, 2007-02-21 at 20:15 +, Mark Seaborn wrote: I profiled make. It's spending around 60% of the time in new_pattern_rule(), which does a linear search through the list of pattern rules to check for duplicate rules. glibc generates ~2500 rules (in sysd-rules). Holy moly! How in the world do you get that many pattern rules?!?! The point of pattern rules is that they represent an entire class of targets, which means you typically would have orders of magnitude fewer pattern rules than you have targets. I don't have anything against making this more efficient, I'm just... surprised. I was considering refactoring this properly, but the current new_pattern_rule() doesn't look quite right. The comment says it looks for an identical rule. The actual test is the old rule has 1 target (or multiple identical targets) and there exists a target in the new rule the same as the old rule's target I agree that this doesn't seem correct. I got your set of patches, and I'll take a look. Thanks! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU MAKE
On Sat, 2007-01-27 at 20:15 -0800, suresh babu wrote: I am interested to do development required for GNU make. Can you give me the details what should I do? Hi Suresh. There are many outstanding issues but nothing jumps out at me at the moment. I'm currently working on two things: memory usage in make (as more inclusive make systems are developed, this is becoming more of an issue), and integration with Guile as a scripting language. I'm also doing some work with controlling output of make (verbosity levels, debugging, etc.) You can try looking through the Savannah site at the bugs and support requests, etc. there and see if anything strikes you as interesting to work on. One thing that would be nice is for someone to put some love into the test suite; not even so much writing new tests as fixing the infrastructure of the test suite itself. I don't know if you're a Perl person or not but that's an opportunity (or integrating with some other existing test infrastructure, I don't know). If you pick something let me know so we don't get duplicate efforts. Cheers! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Parallel Jobs Bug
On Sun, 2007-01-28 at 13:27 -0800, Bill Harding wrote: In regards to Paul's earlier questions about the version and distribution of my make, it is a Cygwin version of make running on Windows XP. Specifically, if I access my make's help it says Program built for i686-pc-cygwin. The version of make is GNU Make 3.80. The Cygwin version of GNU make 3.80 (and below) have some special customizations that aren't part of vanilla GNU make 3.80. I suggest you continue to work with the folks on the Cygwin mailing list to try to resolve this issue. I do find it odd that the errors seemed to suggest you were running cmd.exe, if you're using a Cygwin environment. However, the folks on the Cygwin lists will be better able to advise you. Starting with GNU make 3.81, the cygwin port is supported natively and doesn't involve any extra code modifications (as far as I know). If you still have problems with that version then we may be able to help. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Inconsistent behaviour when building in parallel
On Sat, 2007-01-20 at 22:22 +0100, Dirk Heinrichs wrote: In the parallel case, make does exactly the same thing EXCEPT that instead of waiting for the first command to complete it immediately checks the second target and, since the first command is not done yet and hasn't updated it, make sees that it's still out of date so it runs that rule again to update it. So the left hand doesn't know what the right hand does? I consider this a bad thing. I do too, and so does make: that's why you shouldn't do it. After all, make cannot know what the commands you give it will REALLY do, it can only assume that they will do what you've told it they will do: namely, update the target file. However, in your makefile your commands don't just update the target file that you told make they would, they also update some OTHER target files that you didn't tell make about. So, make doesn't expect the commands to update those target files. In this case, the two hands you refer to are your commands that you wrote and added to your makefile, so you can hardly blame make for what they may be doing behind each others' backs. In the parallel case you can't tell exactly what will happen: it depends on your system; how busy it is, what order the various jobs are scheduled by the OS, how long the command takes to execute, etc. It could work perfectly, or it could be run twice, or more times (if there are more than two targets). That's even worse. Perhaps, but as Eli points out this is a feature of the operating system and is completely out of make's control. When you run multiple commands in parallel on a multitasking system, you cannot control the order in which they are executed. That's the entire point: if they always ran in a fixed order then they wouldn't be parallelized, would they? As Eli says, if you want serialized command execution it's trivial to get from make: just don't enable parallel builds. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Inconsistent behaviour when building in parallel
On Fri, 2007-01-19 at 20:01 +0100, Dirk Heinrichs wrote: I'm using GNU make 3.81 (on Linux, if this is important) and see strange behaviour in parallel builds with the following Makefile: file1.txt file2.txt: file.in cat $ file1.txt|tee file2.txt test: file1.txt file2.txt cat $^ $@ In a normal build, make does the right thing: % make test cat file.in file1.txt|tee file2.txt cat file1.txt file2.txt test In case of a parallel build, the cat ... | tee ... command for file[12].txt is executed twice, which should not happen: % make -j 2 test cat file.in file1.txt|tee file2.txt cat file.in file1.txt|tee file2.txt cat file1.txt file2.txt test Make is behaving correctly here. Multiple targets in a single rule does not mean all these targets are built from one invocation of the rule. It means that each of these targets has the same prerequisites and rule, and will be built one at a time by running the rule. IOW, this: a b c : d e f ; command is identical to writing this: a : d e f ; command b : d e f ; command c : d e f ; command See the GNU make manual for details. You can use pattern rules: %1.txt %2.txt : %.in ... which do work as you expect. Or you have to use a sentinel file. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Inconsistent behaviour when building in parallel
On Sat, 2007-01-20 at 17:35 +0100, Dirk Heinrichs wrote: So if make behaves correctly in the parallel case, does this mean that the non-parallel case is wrong? ?? No, both are correct. In the non-parallel case, make examines the first target and its prerequisites and sees that it needs to be rebuilt, so it runs the rule. The rule updates the first target and also updates the other targets. Next make looks at the second target and its prerequisites and sees that it does NOT need to be rebuilt (because it is newer than all the prerequisites, since it was just updated). So it's not rebuilt. Etc. In the parallel case, make does exactly the same thing EXCEPT that instead of waiting for the first command to complete it immediately checks the second target and, since the first command is not done yet and hasn't updated it, make sees that it's still out of date so it runs that rule again to update it. In the parallel case you can't tell exactly what will happen: it depends on your system; how busy it is, what order the various jobs are scheduled by the OS, how long the command takes to execute, etc. It could work perfectly, or it could be run twice, or more times (if there are more than two targets). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: EAGAIN in read jobs pipe
On Wed, 2007-01-10 at 01:53 -0800, Howard Chu wrote: An essential design choice. This stuff relies on reads and writes of the job_fd being atomic and the writes never blocking. POSIX guarantees a 4K buffer for pipes. Perhaps the code should check the resource limit and complain if the -j argument exceeds the resource limit: Error: why don't you just use '-j' ?? Yes, that's a good idea. I will add some error checking to the code that initially seeds the pipe with tokens. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: EAGAIN in read jobs pipe
On Tue, 2007-01-09 at 10:32 +, James Coleman wrote: Ken Takusagawa wrote: For reasons I haven't completely triaged yet, I've been having my parallel makes die with read jobs pipe: Resource temporarily unavailable. Stop. All memory on machine might be used up (real memory + all swap). I don't think this can be the case. In a standard POSIX system a buffer is allocated to the pipe when it's created. There's no need to get more memory when writing to or reading from the pipe. Further, GNU make simply writes one byte to the pipe for each possible job, so as long as you're not using -j65536 or something silly like that it's unlikely to be a problem. Really, I can't think of why you might get that error on a pipe. In fact, according to the POSIX spec the ONLY time you're allowed to get EAGAIN from a read(2) are: The O_NONBLOCK flag is set for the file descriptor and the thread would be delayed. Since we are not setting O_NONBLOCK on the pipe FD, it should not be possible (according to POSIX) to get back EAGAIN. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: jobserver_fds-list buffer overflow
On Mon, 2007-01-08 at 22:26 -0500, Ken Takusagawa wrote: In main.c we have jobserver_fds-list[0] = xmalloc ((sizeof (1024)*2)+1); sprintf (jobserver_fds-list[0], %d,%d, job_fds[0], job_fds[1]); Shouldn't xmalloc get a +2 instead of +1? 1 for the comma, and one for the null terminator? sizeof(1024) is 5 (the sizeof() a constant string includes the \0 terminator). I'm not sure why we add one, to be honest. Just being extra safe I guess. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: getting warmer error messages
I can only assume you're trying to prove a point by making this bug report virtually unintelligible, with no concrete suggestions for improvement. Well played. Unfortunately for your point, there's a good reason for make's behavior. Pattern rules only match if make can successfully create all the prerequisites in the rule. If one or more cannot be created, then the pattern rule does not match. If no pattern rule matches for a given target (and no explicit rules exist for it), then make can't figure out how to build that target and so it fails with a message saying that target cannot be built. What else should it do? For any given target there are usually many possible pattern rules which it MIGHT match, if it could build the prerequisites. The default pattern rules, by themselves, provide a number of ways of building any file, and a multitude of ways to build some types of file. I don't believe it would be useful for make to print a list of potential targets that, if they could be built, would allow the target you asked for to be built. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: tkConfig
On Wed, 2006-12-20 at 23:43 -0500, Shannon Coffey wrote: I am attempting to compile GCL on a Macintosh. This list is for bugs with the GNU make program itself. If you're having problems building some particular software you should find a mailing list dedicated to that software and ask there for help building it. Good luck! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Problem with CURDIR variable
On Mon, 2006-12-11 at 15:36 +0100, Sombat Ketrat wrote: the error msg. is --- GNUmakefile:3: *** Sorry, your version of GNU make (3.81) is too old. You need one that defines the CURDIR variable. Stop. --- ifneq (default,$(origin CURDIR)) $(error Sorry, your version of GNU make ($(MAKE_VERSION)) is too old. You need one that defines the CURDIR variable) Is it the problem with version of the make (make v.3.8.1-23)? Do you have any idea how to overcome the problem? In GNU make 3.81, the origin of the CURDIR variable was changed from default to file (this was so that an environment variable CURDIR wouldn't override the value make set). This test is kind of strange. Unless there's some specific reason the makefile REQUIRES the CURDIR variable to be set by make, it should be rewritten: ifndef CURDIR $(error Please define the CURDIR variable (or use a newer version of GNU make)) endif Please contact the developers of the molpro software and notify them of this issue. If you don't want to change the makefile you'll have to find an older version of GNU make (3.80 would be OK) and use that instead. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Problem with CURDIR variable
On Tue, 2006-12-12 at 06:29 +0200, Eli Zaretskii wrote: But this test could be defeated if CURDIR was defined in the environment, right? If so, the test should make sure CURDIR doesn't come from the environment. I was assuming that if it was defined, someone set it. But I guess you're right; it could just be set in the environment, to something that's incorrect. They should probably check it to be extra-safe. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: problems with Net-PCap
On Tue, 2006-12-05 at 00:35 +0100, sofia wrote: 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 /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 Could you please answer me?? Hi Sofía; This mailing list is for questions about and problems with GNU make itself. Your issue above it not related to make; rather it's something wrong with the package you're trying to build or perhaps you're missing something that should be installed on your system. Either way, you need to ask this question on a list or in a group that knows about how to build net-pcap; they should be able to provide more help. Good luck! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [Fwd: Slack11.0 /usr/bin/make incompatible with LPRng-3.8.28 Makefile.in]
On Fri, 2006-12-01 at 13:08 -0800, david baker wrote: I'm forwarding a note I sent to Karl Berry [EMAIL PROTECTED] which he advised to be sent to you. Additionally I am attaching screen shots of the actions I took and published on linuxquestions.org and the Makefile.in from LPRng-3.8.28. The GNU Make version which fails is 3.81. The GNU Make version which works is 3.80. David: thanks for sending me the extra info. In the future please remember to CC the mailing list rather than sending things to me directly. The problem is that the LPRng makefile (or Makefile.in as the case may be) is incorrect. In particular, this line is very, very wrong: SHELL=/bin/sh The SHELL make variable is special to make, in that it specifies what program make will invoke to run the commands you provide in your rules. Also, make is not a shell, and make variable syntax is not identical to shell variable syntax. In particular, make variable values do NOT have quotes expanded. The above line, with the quotes, tells make that the shell it should invoke is the literal string /bin/sh (with quotes). That string does not look to make like a normal Bourne shell name, so make doesn't recognize it as such and tries to do something fairly bizarre. I suspect there may be a bug related to this, or at least unexpected behavior. Nevertheless, the above is quite wrong. In general you shouldn't set SHELL at all, but if you must then your Makefile.in should say merely: SHELL = /bin/sh (no quotes). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [Fwd: Slack11.0 /usr/bin/make incompatible with LPRng-3.8.28 Makefile.in]
On Fri, 2006-12-01 at 13:08 -0800, david baker wrote: I'm forwarding a note I sent to Karl Berry [EMAIL PROTECTED] which he advised to be sent to you. Additionally I am attaching screen shots of the actions I took and published on linuxquestions.org and the Makefile.in from LPRng-3.8.28. The GNU Make version which fails is 3.81. The GNU Make version which works is 3.80. Thanks for the report. It would be much more useful if you included the Makefile, not the Makefile.in, since make is actually using the Makefile. I cannot reproduce your problem on my system: I don't get a syntax error when I massage the Makefile.in you included. If you run make clean do you get the same error? If so, please run make -n clean and cut and paste that as well (or redirect to a file and attach it to the email). I'd like to see exactly what the shell invocation looks like that gets an error. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: can't get far if file has difficult name
On Thu, 2006-11-30 at 22:51 +, Jon Grant wrote: Martin Dorey elucidated on 30/11/06 21:32: Isn't this more relevant? (Quoting from here on.) Yeah, Looking at it again I can see that's likely the problem. I might need to reopen that bug; there definitely was a change in behavior WRT filenames containing spaces between 3.80 and 3.81. I need to look at it to see what's going on. I'd be interested to see the same test with odd characters but not whitespace. As far as I know, GNU make is UTF-8 compatible. But I know very little about it. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: can't get far if file has difficult name
On Thu, 2006-11-30 at 16:52 -0800, Martin Dorey wrote: Works for me if I remove the two close-parentheses and replace the white space with underscores. Open-parenthesis fine, close-parenthesis bad. Weird. Close-parenthesis is also bad with Debian sarge's make-3.80. I suspect that has to do with the shell. Although () are not special to make, they are special to the shell, and make's builtin rules don't quote their filename arguments (and neither did Dan's example). You didn't specify what errors you got when you had the parens in there, but in my tests if I have them (unquoted) I get an error from the shell, not from make. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug
On Wed, 2006-11-29 at 13:22 +, Jon Grant wrote: Finally, there is no way to detect an out of stack error and exit gracefully with a warning as you suggest: the behavior of alloca() is undefined if you run out of stack space (it doesn't just return NULL as malloc() etc. do). Is it undefined in actuality though? Has anyone checked if NULL does get returned from any implementations? From the standpoint of GNU make it doesn't matter all that much what some implementations do. In order to be portable it must assume the lowest common denominator. My view would be that on modern computers switching to allocate from the heap wouldn't make a big difference if it were changed. Modern heaps have pools for small allocations to stop them fragmenting larger allocations anyway. Someone would need to do a compressive test to know for sure, these things often have knock on effects.. I've seen massive slowdowns when someone switched malloc() to calloc() on MS-Windows! Well, yes, but changing from malloc() to calloc() actually has a significant difference: in the latter all the memory you've allocated needs to be zeroed out. That can have all kinds of implications even beyond the obvious need to walk all the bytes in each allocation, in terms of swapping, cache issues, etc. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug
On Tue, 2006-11-28 at 18:45 -0800, Martin Dorey wrote: Using heap, which requires a system call to get more memory (It doesn't affect the main point of Paul's reply but just for academic interest) no it doesn't: Even in less contrived applications, brk isn't called anything like as often as malloc. Certainly that's true... I didn't mean to suggest every call to malloc() resulted in a system call. But using the heap DOES require a system call to get memory... obviously the C runtime will grab memory in much larger chunks and maintains a free pool, with algorithms to handle fragmentation and coalescing of free blocks, etc. There are whole dissertations written on the most efficient ways to manage heap :). But (as I'm sure we both agree) alloca() is unquestionably more efficient (assuming you have an appropriate amount of stack). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: plzzzzzzzzzz help
On Tue, 2006-11-28 at 03:48 -0800, rocky john wrote: I am amateur at linux .i am trying to install nagios-2.6.i went through documentations after executing commands make install -commandmode make install -config I got this problem :This program built for i386-redhat-linux-gnu.. My pc is i386 packages compatible..help me out As someone else pointed out, you should be asking for help in the nagios lists. May I suggest that when you ask them, you provide many more details including the exact command you entered, the precise hardware and operating system type and version you're using, the exact errors you got (cut and paste please) including a useful number of lines of context before the error. And most important: please use a subject line that is relevant and coherent! These days, spam is a huge percentage of all email and the open source mailing lists are no exception. In order to allow anyone to report problems and ask for help many OSS mailing lists don't require you to subscribe before posting... that means that someone has to go through and look through the spam to find the messages that should be forwarded to the list. Having a relevant subject that is immediately recognizable as not spam, vs. one that is quite spam-like, greatly decreases the chances of your email being unceremoniously dumped into the bit bucket and makes life a lot easier for us poor saps who have to sort it all out. Good luck! ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: SHELL -c hardwired
On Monday, 6 November, Eli Zaretskii ([EMAIL PROTECTED]) wrote: As far as Make is concerned, I think you can say SHELL=mysql -e and have it your way, no? No. Make is hardcoded to add the -c option; every command make invokes is run with $(SHELL) -c cmd. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [sbashford@mpc-data.co.uk: SHELL query/bug]
%% Regarding [[EMAIL PROTECTED]: SHELL query/bug]; you wrote: sb I'm using make v3.78.1 under MS-Windows2k sb The problem I'm having is that it just doesn't seem to pick up the sb shell that I've specified in my environment variables. sb I've tried combinations of SHELL and MAKESHELL and always a sb different shell that's in my path gets executed. sb I have read the helpfile several times and feel sure that the sb SHELL variable is the one I need to set. sb Any suggestions? 1) Try a newer version of GNU make. 3.78 is kind of old. 2) For Windows-specific questions like this, try asking on the [EMAIL PROTECTED] mailing list instead; most of the more knowledgeable Windows vs. GNU make folks hang out there. -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT: HA Software Mthds Tools 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-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make-3.80: `eval' bug
Hi; After looking at the code I've determined that passing the o is not sufficiently safe. There are sections of the eval() function which call variable_expand(), which will reset the variable_buffer setup. So if you put any of those in your expansion text you'll be sad. So, I'm going with my original push/pop implementation. I've also found another bug: if you use $(eval ...) inside a conditional statement it fails! Doh! I'll fix this shortly. -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT: HA Software Mthds Tools 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-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Whooops...
My previous message should have given the URL as: ftp://alpha.gnu.org/gnu/make/make-3.80rc2.tar.gz ftp://alpha.gnu.org/gnu/make/make-3.80rc2.tar.bz2 not alpha.ftp.org. Sums in my previous email are correct. Sorry for the confusion :( -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT: HA Software Mthds Tools 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-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: pipe read hang on Win 2000 with make 3.79.1
X-Mailer: NIMS ModWeb Module I don't know what this is, but it generates pretty seriously malformed SMTP messages :-/. Using the Win32 port of GNU make 3.79.1 on Windows 2000 with either the = Cygwin shell, or the MKS sh.exe, or even the Windows cmd.exe I get a = hang when running the following makefile: PKGDIR = $(shell echo this.is.a.test | sed 's:\.:/:g') Your best bet is to ask on [EMAIL PROTECTED], but, did you try running this directoy at the command line, without using make's shell function? If that doesn't work, then it's not a make issue at all and you should ask the Cygwin or even the MKS or Microsoft folks. -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT: HA Software Mthds Tools 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-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
