Re: problem with GNU make
Hi, [EMAIL PROTECTED] elucidated on 08/02/07 21:53: i have some old (circa 1997) makefiles which run fine on current UNIX systems with their versions of make. if i run gnu make as make -n then GNU make shows the commands that will be executed just fine however, when i actually issue the make command then none of the commands as reported via make -n are actually executed. is this a known problem; is there a workaround ? Sounds like a configuration problem, just an idea, but are you setting SHELL? Are you running GNU Make v3.81 ? Perhaps you can try with that latest release. If you can post a small reproducible test case, telling us your OS, shell and make version we could help a bit more. Best regards Jon -- Weblog: http://jguk.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: BUG while running the make file
Raheja, Himanshu elucidated on 09/02/07 20:12: Hi Folks..!! I am sorry to bug you again.. This should be the last one... I was able to successfully run LPRng3.8.28 on my RED Hat Linux 4.4. But as my company is already using 3.6.9d version and to avoid some problems I am compiling the code for 3.6.9d After running the configure script I am making changes to makefile by setting the CFLAGS and LDFLAGS = -m32. Then I run make install I get following error messages :(Please help and le me know what needs to be done, I will be grateful ..as always.. :) ) Your build isn't finding the includes. Are you building from a different directory than where "common" exists? does LPRng supply any documentation about building it? Perhaps you can speak to LPRng maitainers, this isn't a compiler support mailing-list. (you need to hire me to get that, hehe ;) Kind regards Jon -- Weblog: http://jguk.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make problems
Hi, Turbo-parts elucidated on 01/03/07 22:03: Hello, allways no targets specified and no makefile found. stop. how can i change ? Sounds like you have a problem with your project + build, check if there is a "Makefile" in the directory; or explain the problem to the person who provided you with the project. Kind regards Jon -- http://jguk.org/2007/02/email-101-rules-for-great-unwashed.html ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: running make 3.81 tests on Mac OS X : was (no subject)
Hi Thomas, thanks for your email. The key part of the make 3.81 testsuite log is this: features/default_names .. Error running /Users/thomas/Desktop/tmp/make-3.81/tests/../make (expected 0; got 512): /Users/thomas/Desktop/tmp/make-3.81/tests/../make ok (4 passed) I don't know of a problem in this area. Does anyone else? Thomas: Could you send that specific diff file in the work dir to this mailing list please? (or send the group if you cant figure out which to send) Regards Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
33 make check failures on Ubuntu Linux
Hello. 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? Kind regards Jon *** work/features/include.base.22007-04-22 14:32:36.0 +0100 --- work/features/include.log.2 2007-04-22 14:32:36.0 +0100 *** *** 1 ! make: *** No rule to make target `foo.mk', needed by `error'. Stop. --- 1 ! make: *** No rule to make target `foo.mk', needed by `error'. Stop. cd tests && perl ./run_make_tests.pl -make ../make -- Running tests for GNU make on Linux now2g 2.6.17-10-generic i686 GNU Make 3.81 -- Finding tests... features/comments ... ok (1 passed) features/conditionals ... ok (4 passed) features/default_names .. ok (3 passed) features/double_colon ... ok (10 passed) features/echoing ok (4 passed) features/errors . ok (2 passed) features/escape . FAILED (4/6 passed) features/export . ok (10 passed) features/include FAILED (6/7 passed) features/mult_rules . FAILED (1/2 passed) features/mult_targets ... ok (2 passed) features/order_only . ok (10 passed) features/override ... ok (1 passed) features/parallelism ok (6 passed) features/patspecific_vars ... ok (7 passed) features/patternrules ... ok (5 passed) features/quoting ok (1 passed) features/recursion .. ok (2 passed) features/reinvoke ... ok (4 passed) features/se_explicit ok (5 passed) features/se_implicit ok (8 passed) features/se_statpat . ok (4 passed) features/statipattrules . ok (8 passed) features/targetvars . ok (20 passed) features/varnesting . ok (1 passed) features/vpath .. ok (1 passed) features/vpath2 . ok (1 passed) features/vpathgpath . ok (1 passed) features/vpathplus .. ok (4 passed) functions/abspath ... ok (1 passed) functions/addprefix . ok (1 passed) functions/addsuffix . ok (2 passed) functions/andor . ok (2 passed) functions/basename .. ok (1 passed) functions/call .. ok (2 passed) functions/dir ... ok (1 passed) functions/error . FAILED (0/5 passed) functions/eval .. FAILED (8/9 passed) functions/filter-out ok (1 passed) functions/findstring ok (1 passed) functions/flavor ok (1 passed) functions/foreach ... FAILED (2/4 passed) functions/if ok (1 passed) functions/join .. ok (1 passed) functions/notdir ok (1 passed) functions/origin ok (1 passed) functions/realpath .. ok (2 passed) functions/shell . ok (2 passed) functions/sort .. ok (1 passed) functions/strip . ok (2 passed) functions/substitution .. ok (3 passed) functions/suffix ok (1 passed) functions/value . ok (1 passed) functions/warning ..
Re: running make 3.81 tests on Mac OS X : was (no subject)
File the bug report at this page: http://savannah.gnu.org/projects/make/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: running make 3.81 tests on Mac OS X : was (no subject)
Hi Thomas,
Thanks for replying with the logs.
default_names tests that Make looks for default makefiles in the correct
order (GNUmakefile,makefile,Makefile). read.c:229 { "GNUmakefile",
"makefile", "Makefile", 0 };
I suggest you file a bug report, I can't spot why why the sequence of
tests looses the "makefile" before it has chance to make use of it.
Please include the output you see when you run "make" in a directory
containing the attached "Makefile" and "makefile".
Then delete the "makefile" and run "make" again in the directory with
only the "Makefile" still present. Also attaching those logs, and the
output of ./run_make_tests -debug
Please include in the bug report how reproducible this is. Hopefully
someone with a Mac OS X machine can take a look.
Kind regards
Jon
--
Weblog: http://jguk.org/
THIRD: ; @echo It chose MakefileSECOND: ; @echo It chose makefile___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: 33 make check failures on Ubuntu Linux
Hi Pau. Thanks for your reply. 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). From bash I needed to do both: $ export LC_ALL=C $ export LANG=C However, I still saw three test failures, (these failures are not in the latest CVS 3.81.90 build I should add). -- Running tests for GNU make on Linux now2g 2.6.17-10-generic i686 GNU Make 3.81 -- [...] features/vpathplus .. FAILED (2/4 passed) [...] options/dash-W .. FAILED (9/10 passed) [...] options/general . ok (1 passed) options/symlinks *** Test died (options/symlinks): scripts/options/symlinks: 22 -> test_driver.pl: 915: Couldn't touch dep: Too many levels of symbolic links Could this message below be updated to remind that "make update" is needed to download the po files? make[4]: Entering directory `/home/now3d/maketest/make/po' File be.po does not exist. If you are a translator, you can create it through 'msginit'. 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). [EMAIL PROTECTED]:~/maketest/make$ locale LANG=en_GB.UTF-8 LANGUAGE=en_GB:en LC_CTYPE=ja_JP.UTF-8 LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= Kind regards Jon -- Weblog: http://jguk.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Build warnings in CVS make 3.81.90
Hello, I noticed a few build warnings in CVS at present. Difficult to spot a lot of the causes as there are many pre-processor macros in use. 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? Would a patch be accepted to change over such pre-processor expressions into native code? Regards, Jon 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 ^^ Looks like the last arg, "int ns" doesn't need to be signed. function.c: In function 'func_lastword': function.c:696: warning: 'p' may be used uninitialized in this function 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' main.c: In function 'main': main.c:1825: warning: comparison of unsigned expression < 0 is always false main.c:2152: warning: comparison of unsigned expression < 0 is always false remake.c: In function 'update_file_1': remake.c:436: warning: comparison of unsigned expression < 0 is always false remake.c: In function 'notice_finished_file': remake.c:869: warning: comparison of unsigned expression < 0 is always false remake.c: In function 'f_mtime': remake.c:1240: warning: comparison of unsigned expression < 0 is always false remake.c:1253: warning: comparison of unsigned expression < 0 is always fa ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Ayundema por favor, Help me please
Hi Ricardo, You can download from here: ftp://ftp.gnu.org/gnu/make or your local mirror. Then just do the usual: $ ./configure;make;make install Or your distro might have a package you can use, ask them and find out! Kind regards, Jon -- weblog: http://jguk.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Make fails on glibc build
Hi. [EMAIL PROTECTED] wrote on 18/05/07 15:08: I rebuilt it and the error came again. Using make from cvs 20070511, binutils 2.17.50.20070518 from cvs, glibc from cvs 20070518, gcc-4.2.0, kernel 2.6.21.1, i686 (make 3.81 works). Using CFLAGS "-march=pentium4 -O2 -pipe -fomit-frame-pointer -s" and configure "--prefix=/tools --disable-nls --disable-dependency-tracking --infodir and --mandir". make -d gives me: Trying rule prerequisite `subdir_lib'. make: file.c:147: enter_file: Assertion `*name != '\0'' failed. Reaping losing child 0x0807f1b8 PID 9716 make: *** [all] Aborted Removing child 0x0807f1b8 PID 9716 from chain. Because I disabled debug for make I rebuilt it with standard CFLAGS. But how can I help you to solve the problem? Never worked with a debugger yet. Do you mean you have never worked with a debugger? I'm not certain, but that assertion should then call abort(), which means a core file will be dumped. (Just do ulimit -c 5 in your shell before you run make, to be sure core files are not disabled on your distro). then you can do gdb -c core.xxx -se /path/to/make then "bt" to get the backtrace of the assert. Cheers, Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Make fails on glibc build
Hi Alexander, Thanks for getting back to us with that backtrace. Unfortunately the debug symbols seem to be missing. I tried to get more info out myself of your core file, but without the CVS binary I just get: Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". Core was generated by `make -r PARALLELMFLAGS= CVSOPTS= -C ./libc objdir=/tmp/bla/glibc-cvs-build all'. Program terminated with signal 6, Aborted. #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0x4005091b in ?? () (gdb) Could you rebuild make-cvs with CFLAGS=-g3 please. And then launch again using the /tmp/make-cvs/make/make binary directly (in case it is being stripped when it is being installed on your system). I wonder what configuration options and you built with, because I though NDEBUG is on the standard make build, which would mean assert() would compile out. Then do: gdb -c core -se /tmp/make-cvs/make/make Then "bt" as before, it should have managed to load the symbols by then. I don't know what distro you are running, but my Ubuntu has packagte suffixed with -dbg, like "libc6-dbg" which can be installed, then all the libc methods will have names. I wonder about this /tools/lib/libc.so.6 file in your backtrace though. I've not seen such a library path myself, what distro, version and CPU are you running on? Linux From Scratch...? If so, perhaps you try reproduce the problem on an existing stable released distro like Ubuntu you have on another PC. Let us know how you get on. Kind regards, Jon ___ 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
Hi, Paul Smith wrote on 11/05/07 20:15: 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, K&R-only compilers as of 3.82, I'm still requiring ANSI C89 clean code, and inline is not valid C89. Ok, well just a change to functions (not using the inline keyword) then. (Compilers tend to make their own mind up anyway on inlining in my experience anyway) -- Would you consider patches which replaced macros with functions? Const integers are legal of course, but I don't know that they really add much clarity. One benefit is the code you see is the code that was compiled. Macros can be replaced during pre-processing and code editors may not visualise the value as it ended up being compiled. Also we get types on the thing being defined etc. My programming books probably have more rational examples. 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. Ok, I'll take a look when I get time. Kind regards, Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Error in kernel module
Hi Ajay, " This program is built for i686-redhat-linux-gnu report bugs to Isn't that just the standard output ? You can see that text on "make --help" make *** [all] Error2 " This is the actual error. As you've not included the full output it is not clear what the problem is with your setup (or environment). could you please let me know what is the issue. Post again with some more information and we can try help. Alternatively, can you compare your makefile with a working one from a different kernel module? Just go through it line-by-line. Kind regards Jon ___ 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 environment lists are too long
Hi, [EMAIL PROTECTED] wrote on 10/08/07 21:33: gnumake[1]: execvp: /bin/sh: The parameter or environment lists are too long. gnumake[1]: *** [clean] Error 127 I've not seen this myself, looks like a hard coded system limit. is the environment list longer than 32KB? Too allow someone to look further, please provide steps to reproduce, including makefile, OS and make --version info. Kind regards Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Adding Makefile.mak to default file names searched
Could we considering adding Makefile.mak to the default filename permutations which are looked for? rationale: I often see Makefiles which are called Makefile.mak, because that is the extension of other make(s) on different OSs. Also it is more convenient on Windows because then it can be associated with a text file editor, when there is no extension it's necessary to manually open it. Kind regards Jon ___ 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 environment lists are too long
Would it be an idea to include the ARG_MAX size in the error message (if that is generated by make? function.c:1738 func_shell). And even include a copy of the text and environment when running in debug mode? I had to breakup a codebase into several libraries to overcome the command-line/enviroment limit previously myself. Kind regards Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bonjour
Hi. You've emailed the GNU Make mailing list, you can get help about the qt and qtbittorrent package from your provider. However, your email included many of the possible answers to the problem you are having with Qt, like setting $QTDIR correctly and reading the conf.log. I suggest you verify all those points before mailing the same info to another mailing list. Kind regards, Jon -- linkme: http://www.linkedin.com/in/jongrant weblog: http://jguk.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: possible memory leak in make 3.81
Paul Smith wrote on 14/10/07 17:39: On Sun, 2007-10-14 at 20:40 +0800, Zhongxing Xu wrote: In function library_search(), libpatterns and buf is malloced memory in line 1486 and 1553 respectively. They are not freed. Is this true? Correct, they are not freed--but no, this is not a memory leak. These variables are declared static so the next time the function is invoked they still point to that same memory buffer. This is just a way to avoid allocating/freeing a local memory buffer over and over. Do they get free'd up when make exits? Would be neater to cleanup any heap allocations, IMHO. Makes it less cloudly when tracking other memory-leaks as well. Cheers, Jon -- linkme: http://www.linkedin.com/in/jongrant weblog: http://jguk.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: possible memory leak in make 3.81
Hi there, Paul Smith wrote on 14/10/07 22:17: On Sun, 2007-10-14 at 18:33 +0100, Jon Grant wrote: Do they get free'd up when make exits? No. It's quite difficult to do this since the variables are static and so are only visible within that function. In order to free them we'd have to add them to some kind of global free list that could be walked when make was exiting. This will take time when all we want to do is exit... and anyway, the operating system will take care of cleaning that up when we exits. the OS should cover that, but in some case I wonder if there may be a leak left. Would the DOS version for instance result in lost memory the OS cannot reallocate? (I'm not a DOS expert to answer that) I'm confident that running such cleanup code wouldn't add a performance cost. Would be neater to cleanup any heap allocations, IMHO. Makes it less cloudly when tracking other memory-leaks as well. I don't think this is a real issue; all the tools I've used for this, including things like Purify as well as free tools like Valgrind, only count memory as lost if there's nothing pointing to that memory anymore. Since this memory still has valid pointers to it, it's not a problem. Are there particular tools that you are thinking of that run into this? Devpartner's boundschecker shows up such heap allocations in its log as "allocations outstanding on program exit" (or some such similar description). BTW, I wonder if you run all the different tests in the testsuite through valgrind? An automated way of doing that would be really handy I think.. I did that for a client recently. Regards, Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: gcc error upon trying to compile the open source prorex-1.3
Please see my other reply. You only need to email the mailing list once! Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: prorex-1.3 make bug
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. Kind regards Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
GNU Make read from makefile.mak files?
Hello I see a lot of projects name their makefiles "makefile.mak" or even "makefile.mk". microsoft NMAKE uses makefile.mak as well. It would be a change, but would GNU Make consider searching for "makefile.mak" as well as the usual "GNUMakefile" "Makefile" and "makefile"? I'm not on this list, so please include my email address in any replies. Best regards, Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
including makefile name and line number for shell_function_completed
Hello I am using make 3.81 built for MinGW. How easy to output the Makefile.mak:line for each command that fails to start? I saw this function is what outputs the error, but not sure how to get file and line number info. Any ideas? Thanks, Jon shell_function_completed if (werr) fprintf(stderr, "make (e=%d): %s", exit_code, map_windows32_error_to_string(exit_code)); ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
makefile target "all:" not built automatically
Hello I noticed that the "all:" target must be at the top of a makefile, unless explicitly built by "make all". Is this expected? It seems quite limiting.. I'm running GNU Make 3.81, built for Windows32. Please retain my email address in any replies. Best regards, Jon Output: C:\>make system target C:\>make all system target all target C:\> = save the following text as "makefile" in an empty folder. # Simple makefile example .PHONY: system system: @echo system target all: system @echo all target # End simple makefile example ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: makefile target "all:" not built automatically
Hello Paul On 26 April 2011 13:34, Paul Smith wrote: > On Tue, 2011-04-26 at 13:31 +0100, Jon Grant wrote: >> I noticed that the "all:" target must be at the top of a makefile, >> unless explicitly built by "make all". Is this expected? It seems >> quite limiting.. > > There is nothing special about the "all" target. That's just a > convention that many, but not all, makefile authors use. Make itself > doesn't treat the "all" target, if it exists, in any special way. > > The GNU make manual says: > >> The order of rules is not significant, except for determining the >> "default goal": the target for `make' to consider, if you do not >> otherwise specify one. The default goal is the target of the first >> rule in the first makefile. Thank you for this. Could the text be updated to confirm that "the target all: does not need to be the default target, this is a convention that many, but not all, makefile authors use. Make itself does not treat the "all" target, if it exists in a special way." I could not find a mention of the "all" target in manual sections. Perhaps it could even be mentioned in this chapter that "all" is not a special target: http://www.gnu.org/s/hello/manual/make/Special-Targets.html Best regards, Jon ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Short option for make --warn-undefined-variables
Hello Could a short option be added for the following make option please? --warn-undefined-variables Warn when an undefined variable is referenced. I propose -u Please keep my email address in any replies. Best regards, Jon ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
makefile line number when errors
Hello I am interested to know if anyway to see the line number in the output. I've got some huge makefiles, and is hard to track down the line with the error sometimes. I include an example below. On Windows this looks like: c:\>make -f test.mk unknown-exe process_begin: CreateProcess(NULL, unknown-exe, ...) failed. make (e=2): The system cannot find the file specified. make: [build] Error 2 (ignored) On GNU+Linux this looks like: $ make -f test.mk unknown-exe make: unknown-exe: Command not found make: [build] Error 127 (ignored) Would be great if it could output: "make: test.mk:5 unknown-exe: Command not found" Not really sure why, but the - on the beggining of the "-unknown-exe" seems to cause the error to be (ignored). Please keep my email address included in any replies. Best regards, Jon # example makefile build: -unknown-exe #end example makefile ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: makefile line number when errors
On 6 May 2011 16:25, Eli Zaretskii wrote: >> Date: Thu, 5 May 2011 22:30:04 +0100 >> From: Jon Grant >> >> c:\>make -f test.mk >> unknown-exe >> process_begin: CreateProcess(NULL, unknown-exe, ...) failed. >> make (e=2): The system cannot find the file specified. >> make: [build] Error 2 (ignored) >> >> >> On GNU+Linux this looks like: >> >> $ make -f test.mk >> unknown-exe >> make: unknown-exe: Command not found >> make: [build] Error 127 (ignored) >> >> >> >> >> Would be great if it could output: >> >> "make: test.mk:5 unknown-exe: Command not found" > > It can't do that without losing important functionality. Unlike Unix, > Windows has too many subtle ways of invoking programs that Make > doesn't support (e.g., via file association). By passing the command > through CreateProcess, we give the OS the last chance to run the > command if it knows how. If it doesn't, you will see this text, which > comes from the error code 2. > > Why does the exact text bother you? Are you perhaps working with some > script that makes unduly stringent assumptions about Make error > messages? It shouldn't: the exact error messages are system > dependent. Sorry, perhaps I was unclear. I am interested in the "test.mk:5" text. I don't mind the specific details or error code which is output later in the line. Just the line number is my request. I would like to track down the line in a makefile which has an issue. In the same way that my C compiler outputs file and line information when it has a build error. Best regards, Jon ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: makefile line number when errors
Hello Eli Zaretskii wrote, On 06/05/11 21:23: Date: Fri, 6 May 2011 21:01:24 +0100 From: Jon Grant Cc: bug-make@gnu.org Sorry, perhaps I was unclear. I am interested in the "test.mk:5" text. I don't mind the specific details or error code which is output later in the line. Just the line number is my request. Sorry for my misunderstanding. Does the --trace switch do what you want? I typed "make --trace -f test.mk" but it did not work. Sorry, perhaps I have miss-understood how to set this option? Perhaps there is an FAQ. I looked in the Make manual. I also tried "make -d -f test.mk" but that did not print line numbers. Best regards, Jon ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: debug report for murphi script
On 19/07/06 14:17, [EMAIL PROTECTED] wrote: Dear Sir/Madam, the attached file is the error i got when "make" the murphi script named rrp.m i can not get the rrp.c and i got message says limited range of data type. please advice me how to debug this type of error. === /usr/etc/Murphi3.1/include/mu_system.C:728: warning: comparison is always false due to limited range of data type make: *** [rrp] Error 1 === The type is probably being checked for a size bigger than it is. like: if(boolvar > -1) or some such situation with an int or float etc. You may like to speak to the people who provided you with the source code. Kind regards JG -- WWW: http://jguk.org/ IM: [EMAIL PROTECTED] ICQ: 11122941 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
Hi! On 27/07/06 20:50, Bob Rossi wrote: Hi, Is it true that 3.81 does not work with windows paths? If so, what is the solution now? I need to use the unix path interally to make, and use the windows path only when compiling with cl? Could you be a little more specific with what you mean by "windows paths"? Spaces are often an issue with MS-Windows filenames, is that what you mean? README.W32 contains info about the Win32 port. Here is the section on pathnames etc: Pathnames and white space: Unlike Unix, Windows 95/NT systems encourage pathnames which contain white space (e.g. C:\Program Files\). These sorts of pathnames are legal under Unix too, but are never encouraged. There is at least one place in make (VPATH/vpath handling) where paths containing white space will simply not work. There may be others too. I chose to not try and port make in such a way so that these sorts of paths could be handled. I offer these suggestions as workarounds: 1. Use 8.3 notation. i.e. "x:/long~1/", which is actually "x:\longpathtest". Type "dir /x" to view these filenames within the cmd.exe shell. 2. Rename the directory so it does not contain white space. If you are unhappy with this choice, this is free software and you are free to take a crack at making this work. The code in w32/pathstuff.c and vpath.c would be the places to start. Pathnames and Case insensitivity: Unlike Unix, Windows 95/NT systems are case insensitive but case preserving. For example if you tell the file system to create a file named "Target", it will preserve the case. Subsequent access to the file with other case permutations will succeed (i.e. opening a file named "target" or "TARGET" will open the file "Target"). By default, GNU make retains its case sensitivity when comparing target names and existing files or directories. It can be configured, however, into a case preserving and case insensitive mode by adding a define for HAVE_CASE_INSENSITIVE_FS to config.h.W32. For example, the following makefile will create a file named Target in the directory subdir which will subsequently be used to satisfy the dependency of SUBDIR/DepTarget on SubDir/TARGET. Without HAVE_CASE_INSENSITIVE_FS configured, the dependency link will not be made: subdir/Target: touch $@ SUBDIR/DepTarget: SubDir/TARGET cp $^ $@ Reliance on this behavior also eliminates the ability of GNU make to use case in comparison of matching rules. For example, it is not possible to set up a C++ rule using %.C that is different than a C rule using %.c. GNU make will consider these to be the same rule and will issue a warning. SAMBA/NTFS/VFAT: I have not had any success building the debug version of this package using SAMBA as my file server. The reason seems to be related to the way VC++ 4.0 changes the case name of the pdb filename it is passed on the command line. It seems to change the name always to to lower case. I contend that the VC++ compiler should not change the casename of files that are passed as arguments on the command line. I don't think this was a problem in MSVC 2.x, but I know it is a problem in MSVC 4.x. The package builds fine on VFAT and NTFS filesystems. Most all of the development I have done to date has been using NTFS and long file names. I have not done any considerable work under VFAT. VFAT users may wish to be aware that this port of make does respect case sensitivity. FAT: Version 3.76 added support for FAT filesystems. Make works around some difficulties with stat'ing of files and caching of filenames and directories internally. === -- WWW: http://jguk.org/ IM: [EMAIL PROTECTED] ICQ: 11122941 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Tiny project to play with gmake ?
Hi, Why not build GNU Make? ;) Cheers Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: plzzzzzzzzzz help
Hello Not sure what would cause your problem, we would need to see a complete log your commands to give a suggestion. You have come through to the GNU Make mailing list, rather than the Nagios team. Perhaps you can contact the Nagios project team, their website is http://nagios.org/ Cheers Jon ___ 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
Hi, Paul D. Smith elucidated on 29/11/06 02:27: [...] > 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? (I'm surprised alloca() implementations didn't end up getting NULL returned in implementations over the years. The GLIBC Manual indicates a fatal signal is generated from its implementation: http://www.gnu.org/software/libc/manual/html_node/Disadvantages-of-Alloca.html 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! Jon ___ 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
Hi Dan Jacobson elucidated on 30/11/06 17:14: > $ cat Makefile > .PRECIOUS:.%.time > %.t:.%.time; > .%.time:% > bla bla bla > $ ls -1 > Makefile > 霧峰-桐林(有經朝陽科技大學) - Wufeng-Tonglin (Via Zhaoyang Technical University) > > Well, no amount of quoting will enable me to > $ make '霧峰-桐林(有經朝陽科技大學) - Wufeng-Tonglin (Via Zhaoyang Technical > University)'.t > make: *** No rule to make target ... If those Asian characters are a filename you need to specify -f filename when you call make if you would like to process that file. Otherwise if you would like to process your "Makefile" Just call "make" with no arguments. Cheers Jon ___ 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
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. Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
