[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Follow-up Comment #5, bug #65908 (group make): [comment #4 comment #4:] > > it would be better that make provides the infos about that line not mis-matched `endif'. > > Sorry but I don't understand what you mean by "that line". Which line is it that make should provide info about? In this case

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Update of bug #65908 (group make): Item Group: Bug => Enhancement ___ Follow-up Comment #4: > it would be better that make provides the infos about that line not mis-matched `endif'. Sorry bu

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Follow-up Comment #3, bug #65908 (group make): Then, it would be better that make provides the infos about that line not mis-matched `endif'. ___ Reply to this item at: __

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

On Sat, 22 Jun 2024 15:49:26 + Martin Dorey wrote: > Um, Henrik... 4.4.90 is the latest in git: Yes, I now see that you are right and that has been the "version number" of all commits in git since version 4.4.1. > ...the de facto OS/2 maintainer... Whoops, my bad... I did remember when supp

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Follow-up Comment #2, bug #65908 (group make): You should review this Git patch: https://public-inbox.org/git/9d14c08ca6cc06cdf8fb4ba33d2470053dca3966.1712591504.git...@ttaylorr.com/ See this section of the GNU Make manual: > Extra spaces are allowed and ignored at the beginning of the condition

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Follow-up Comment #1, bug #65908 (group make): I see line 3857 is the end of Makefile... and that the likely reason the testcase is so large is because it's hard to work out where the if/endif matching has gone astray. For me, running on Linux, the error initially reported is different: mad@shu

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

; psm...@gnu.org ; bo...@kolpackov.net ; bug-make@gnu.org Subject: Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop. * EXTERNAL EMAIL * On Sat, 22 Jun 2024 16:57:17 +0200 Henrik Carlqvist wrote: > > Used make is 'GNU Make v4.4.90'

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

On Sat, 22 Jun 2024 16:57:17 +0200 Henrik Carlqvist wrote: > > Used make is 'GNU Make v4.4.90' from git repo whose head is commit e3f938, > > and I'm working on OS/2. > > > > v4.4.1 works fine. > > In lack of OS/2 maintainer the official GNU Make dropped support for OS/2 > somewhere around vers

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

> Used make is 'GNU Make v4.4.90' from git repo whose head is commit e3f938, > and I'm working on OS/2. > > v4.4.1 works fine. In lack of OS/2 maintainer the official GNU Make dropped support for OS/2 somewhere around version 4.4. It seems as if some unofficial fork was done at https://github.com

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

URL: <https://savannah.gnu.org/bugs/?65908> Summary: Make fails with 'Makefile:3857: *** missing 'endif'. Stop. Group: make Submitter: lvzuufx Submitted: Sat 22 Jun 2024 01:44:50 PM UTC

[bug #63044] Make fails to update .LOADED when the setup routine returns -1.

Update of bug #63044 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

[bug #63044] Make fails to update .LOADED when the setup routine returns -1.

Additional Item Attachment, bug #63044 (project make): File name: sv63044_fix.diff Size:0 KB File name: sv63044_test.diff Size:1 KB

[bug #63044] Make fails to update .LOADED when the setup routine returns -1.

Follow-up Comment #1, bug #63044 (project make): Make fails to add a loaded shared object to .LOADED when the shared object setup routine returns -1. $ ls makefile timer2.c $ cat timer2.c int plugin_is_GPL_compatible; int timer2_gmk_setup (void) { return -1; } $ gcc -o timer2.so

[bug #63044] Make fails to update .LOADED when the setup routine returns -1.

URL: <https://savannah.gnu.org/bugs/?63044> Summary: Make fails to update .LOADED when the setup routine returns -1. Project: make Submitter: dgoncharov Submitted: Sun 11 Sep 2022 01:46:28 AM UTC Sever

[bug #57866] make fails to recognize dependency and substitute variables

Update of bug #57866 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Hi: the behavior you'r

[bug #57866] make fails to recognize dependency and substitute variables

URL: <https://savannah.gnu.org/bugs/?57866> Summary: make fails to recognize dependency and substitute variables Project: make Submitted by: None Submitted on: Thu 20 Feb 2020 09:00:41 AM UTC Severity: 3 -

[bug #44555] "make" fails to use parallelism

Follow-up Comment #16, bug #44555 (project make): Hi! I am sad to say, I missed that this bug had been fixed at the time. Thank you so much for incorporating the fix! I can confirm that using make 4.2.1 fixes this problem for us, and we no longer have to carry this patch locally. Additionally,

Better error message when make fails to remake -include'd makefiles

Hello, I searched in the bugs listed on Savannah but couldn’t find anything mentioning that. I have the following Makefile: $ cat Makefile a.mk: @false -include a.mk This is just to simulate the case when the recipe for an included Makefile fails. When I run make (4.2.1) with this Ma

[bug #49681] Make fails to glob lib/*.{o,a}

Update of bug #49681 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Any commands inside a

Re: [bug #49681] Make fails to glob lib/*.{o,a}

anonymous reported: > This is a regression from GNU make 4.0. The make target > > clean: > rm lib/*.{o,a} > > fails to remove files lib/foo.o, lib/bar.o, and lib/libfoobar.a because > lib/*.{o,a} does not glob lib/*.o and lib/*.a, as is its intention. This is a rule, which make hands off

[bug #49681] Make fails to glob lib/*.{o,a}

URL: <http://savannah.gnu.org/bugs/?49681> Summary: Make fails to glob lib/*.{o,a} Project: make Submitted by: None Submitted on: Wed 23 Nov 2016 12:18:08 PM UTC Severity: 3 - Normal Item Grou

[bug #44555] "make" fails to use parallelism

Update of bug #44555 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #44555] "make" fails to use parallelism

Follow-up Comment #14, bug #44555 (project make): This has become off-topic for the current bug report and anyway it was discussed exhaustively back then; details are in mail archives. But in any case, whether you agree or disagree after reading, it's water well past the bridge by now. __

[bug #44555] "make" fails to use parallelism

Follow-up Comment #13, bug #44555 (project make): "The new feature allowing for pattern-rules...added a lot of complexity and had some performance impacts" Why then was it pushed, given that it changed a convention of file-order vs. best-fit order? ___

[bug #44555] "make" fails to use parallelism

Follow-up Comment #12, bug #44555 (project make): Bisecting between 3.81 and current Git HEAD will not be very productive. 3.81 was released almost 10 years ago. There have been many performance regressions, and many performance improvements over that time. It's likely that some of the regressi

[bug #44555] "make" fails to use parallelism

Follow-up Comment #11, bug #44555 (project make): Following up on Jeff's comment, there are multiple performance regressions after make 3.81. The fork/vfork is the most significant one, but not the only one. These perf regressions are serious problems and upgrading from 3.81 would still cost a sma

[bug #44555] "make" fails to use parallelism

Follow-up Comment #10, bug #44555 (project make): OK, I'll put it back for the next release. ___ Reply to this item at: ___ Message sent via/by Savannah

[bug #44555] "make" fails to use parallelism

Follow-up Comment #9, bug #44555 (project make): While it doesn't account for the full 2.5+ minutes difference, "strace -c"'s summary of syscalls shows that vfork() in a good version of make is less than .02s, while fork() (show as clone()) in a bad version is about 75s (547us/call), a difference

[bug #44555] "make" fails to use parallelism

Follow-up Comment #8, bug #44555 (project make): I see absolutely the same results as noted. And there is NO DOUBT that the fork/vfork is to blame! I tested today on any single commit since 3.75(over 1000 versions!), and every single one of those versions up to 94735f0ad7f67c56afa1513381c73e8f62

[bug #44555] "make" fails to use parallelism

Follow-up Comment #7, bug #44555 (project make): (I am the original bug submitter and poster of the early anonymous comments) Is there additional information I can furnish to help in the resolution of this bug? Were you able to reproduce the problem with the script back in comment #2? _

[bug #44555] "make" fails to use parallelism

Follow-up Comment #6, bug #44555 (project make): I can confirm the bug report and that reverting 94735f0 solves the problem. For us this is a very critical problem, since build times are increased so drastically. ___ Reply to this item at:

[bug #44555] "make" fails to use parallelism

Follow-up Comment #5, bug #44555 (project make): Well, I don't want to move back to vfork() "just because it works", without understanding the situation better. The reasons we switched away from vfork() (portability and correctness) are still issues. I will need to investigate this more deeply t

[bug #44555] "make" fails to use parallelism

Follow-up Comment #4, bug #44555 (project make): We've now deployed our patched GNU make with the patch from comment #2 and the results are positive--the performance regression seen in GNU make 4.x is fixed. Is there any additional information I can provide to allow you to incorporate this fix in

[bug #44555] "make" fails to use parallelism

Follow-up Comment #3, bug #44555 (project make): To reply to a few points I didn't specifically address in my last comment: * make isn't actually dropping into single-job mode, as can be seen from "make --debug=j", but for some reason it's having trouble starting as many jobs as requested. * no,

[bug #44555] "make" fails to use parallelism

Follow-up Comment #2, bug #44555 (project make): I share your surprise that fork vs vfork could possibly have an important performance impact, but *it's what git bisect told me *testing immediately before the commit, I did not encounter the problem *testing at the tip of master with the commit rev

[bug #44555] "make" fails to use parallelism

Follow-up Comment #1, bug #44555 (project make): How do you know that it falls back to one job at a time? Does make actually print out the message it usually does when it gives up on parallelism? Or, do you just observe the build taking a long time and watch the commands being invoked, and see t

[bug #44555] "make" fails to use parallelism

URL: <http://savannah.gnu.org/bugs/?44555> Summary: "make" fails to use parallelism Project: make Submitted by: None Submitted on: Mon 16 Mar 2015 07:33:02 PM UTC Severity: 3 - Normal

[bug #15968] make fails trying to stat a .PHONY target: p\:foo

Summary: make fails trying to stat a .PHONY target: p\:foo => make fails trying to stat a .PHONY target: p:foo ___ Follow-up Comment #2: I cannot reproduce the problem in Make 4.0: the phony target file is never passed to `stat`. So I pres

[bug #15968] make fails trying to stat a .PHONY target: p\:foo

Update of bug #15968 (project make): Component Version: SCM => 3.81 Summary: make fails trying to stat a .PHONY target: p\:foo => make fails trying to stat a .PHONY target:

[bug #38626] make fails on windows with antivirus software

Update of bug #38626 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

[bug #38626] make fails on windows with antivirus software

URL: <http://savannah.gnu.org/bugs/?38626> Summary: make fails on windows with antivirus software Project: make Submitted by: None Submitted on: Fri 29 Mar 2013 03:09:03 PM UTC Severity: 3 - Normal

[bug #107] Make fails when it could re-exec, and then succeed.

Follow-up Comment #2, bug #107 (project make): Just to point out this works fine if you tell make to ignore errors during builds using "-include": ~$ cat /tmp/foo.mk there: hi ; @echo there a.mk: ; echo 'b.mk: ; echo "hi: ; @echo hi" > $$@' > $@ -include a.mk -include b.mk ~$ ./src/make/make-re

[bug #33125] make fails building android build environment due to memory corruption

Follow-up Comment #8, bug #33125 (project make): I added a regression test with my fix. It won't show any difference in behavior unless you run it in valgrind or similar though. ___ Reply to this item at:

[bug #33125] make fails building android build environment due to memory corruption

Follow-up Comment #7, bug #33125 (project make): I also create a test case for regression testing. It's pretty trivial, I'm attaching it here. I'm just unsure in which script this should be added to. Presumably functions/sort. Please do as seems fit. (file #23337) ___

[bug #33125] make fails building android build environment due to memory corruption

Update of bug #33125 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #33125] make fails building android build environment due to memory corruption

Follow-up Comment #5, bug #33125 (project make): Find the captured string attached (excerpt of a debug output). If you analyze it in a hex dumper, you'll see a number of LF / space combinations. Because the splitting function does not split at LFs, it creates a number of single LF tokens split by

[bug #33125] make fails building android build environment due to memory corruption

Follow-up Comment #3, bug #33125 (project make): So I'm happy to make this change, because it does seem cleaner, but I must confess I don't understand how the original error is caused by it. The code uses isspace() to count spaces the first time through the list. isspace() matches spaces and tab

[bug #33125] make fails building android build environment due to memory corruption

Follow-up Comment #4, bug #33125 (project make): I understand your puzzlement - the more I think about it the less I personally understand... I will capture the string - there is no easy test case, because the android build system isn't exactly trivial. It was only found due to corruption in free

[bug #33125] make fails building android build environment due to memory corruption

Follow-up Comment #2, bug #33125 (project make): Please use ONLY the revised patch; it doesn't change whitespace handling in tokenization, which introduced an incompatible semantic change. The revised patch only fixes array counting as considered in the original report. All test cases are workin

[bug #33125] make fails building android build environment due to memory corruption

Follow-up Comment #1, bug #33125 (project make): Just found that this apparently breaks test variables/define. Analyzing. ___ Reply to this item at: ___

[bug #33125] make fails building android build environment due to memory corruption

URL: <http://savannah.gnu.org/bugs/?33125> Summary: make fails building android build environment due to memory corruption Project: make Submitted by: mshopf Submitted on: Tue 19 Apr 2011 01:37:36 PM GMT Sever

[bug #29242] make fails to check timestamp of .h file and declares .o files are upto date

Update of bug #29242 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: If you have no makefi

[bug #29242] make fails to check timestamp of .h file and declares .o files are upto date

URL: <http://savannah.gnu.org/bugs/?29242> Summary: make fails to check timestamp of .h file and declares .o files are upto date Project: make Submitted by: None Submitted on: Wed 17 Mar 2010 07:13:09 AM UTC Sever

[bug #17740] make fails without any message

Update of bug #17740 (project make): Status:None => Fixed Assigned to:None => bosk Open/Closed:Open => Closed Fixed Release:

[bug #14684] make fails if LC_CTYPE is iso_8859_1

Update of bug #14684 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #12: I'm closing this as

Re: Make fails on glibc build

Here is a new backtrace from a rebuilt toolchain without optimization and full debugging :) (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0x4004d9ba in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x4004eff7 in *__GI_abort () at abort.c:88 #3 0x4004709e in *__GI__

Re: Make fails on glibc build

Thanks for the help Jon :) A core was dumped (couldn't be attached because it bounced back) and I tried gdb. The output was: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0x4005091b in raise () from /tools/lib/libc.so.6 #2 0x40051e1e in abort () from /tools/lib/libc.so.6 #3 0x0041 in ?? (

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

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"

Re: Make fails on glibc build

7 14:45:09 > An: Alexander Kahl <[EMAIL PROTECTED]> > CC: bug-make@gnu.org > Betreff: 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) faile

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 prod

Make fails on glibc build

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 ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig

[bug #17740] make fails without any message

Follow-up Comment #5, bug #17740 (project make): I am pretty sure this is related to (or even the same as) bug #15110. ___ Reply to this item at: ___ M

[bug #17740] make fails without any message

Follow-up Comment #4, bug #17740 (project make): Here's a Makefile and test procedure that produces 4 (related) symptoms. Please let me know if I can provide any other information. Is there any chance that Make does not catch and/or propagate non-zero exit status properly when it occurs while p

[bug #17740] make fails without any message

Follow-up Comment #3, bug #17740 (project make): Someone who sees this problem will need to either provide a reproducible test case, or a description clear enough to allow me to create one. Based on the information in this bug I tried this: include foo.d foo.d: foo.x ; : cp $< $@ all: ; :

[bug #17740] make fails without any message

Follow-up Comment #2, bug #17740 (project make): Here's another data point. "make -k" partially exposes a silent error: [EMAIL PROTECTED]> make_ [EMAIL PROTECTED]> make_ -k make_: Target `default' not remade because of errors. -- Tony

[bug #17740] make fails without any message

Follow-up Comment #1, bug #17740 (project make): I, too, have seen this problem when automatically building and including dependency makefiles (for C++ headers). I'd really like to see it resolved. The silent failure can cause users to lose a lot of time since there are no hints what is wrong whe

[bug #17740] make fails without any message

URL: <http://savannah.gnu.org/bugs/?17740> Summary: make fails without any message Project: make Submitted by: None Submitted on: Thursday 09/14/2006 at 13:44 UTC Severity: 3 - Normal Item Grou

Re: [bug #14684] make fails if LC_CTYPE is iso_8859_1

%% Ben Pfaff <[EMAIL PROTECTED]> writes: bp> "Paul D. Smith" <[EMAIL PROTECTED]> writes: >> It looks like for Solaris 10 they introduced an implementation >> of isblank() into the standard header files, which didn't used >> to be there (it's not on my Solaris 8 system for example). bp>

[bug #14684] make fails if LC_CTYPE is iso_8859_1

Follow-up Comment #11, bug #14684 (project make): This is pretty clearly a bug in Solaris; the POSIX spec says: blank Define characters to be classified as s. In the POSIX locale, only the and shall

[bug #14684] make fails if LC_CTYPE is iso_8859_1

Follow-up Comment #10, bug #14684 (project make): Yes. I tracked the problem down to the locale definition file for iso_8859_1, in which the character class blank is defined as: blank; Of the non-unicode locales, iso_8859_1 seems to be the only one broken in this respect (I haven't

Re: [bug #14684] make fails if LC_CTYPE is iso_8859_1

"Paul D. Smith" <[EMAIL PROTECTED]> writes: > It looks like for Solaris 10 they introduced an implementation > of isblank() into the standard header files, which didn't used > to be there (it's not on my Solaris 8 system for example). For what it's worth, the isblank() function was added to the s

[bug #14684] make fails if LC_CTYPE is iso_8859_1

Follow-up Comment #9, bug #14684 (project make): Aha! That macro, isblank(), is actually defined by GNU make to be something very simple which will obviously always match '\t'. Except when it isn't defined by GNU make, and it isn't defined by GNU make when the system already defines it! It loo

[bug #14684] make fails if LC_CTYPE is iso_8859_1

Follow-up Comment #8, bug #14684 (project make): On Solaris 10, with LC_CTYPE set to iso_8859_1, isblank returns zero for isblank('\t'), which (at least for me) causes the problem described in the original report. The following program demonstrates the issue: #include #include #include int

[bug #15968] make fails trying to stat a .PHONY target: p:foo

Update of bug #15968 (project make): Item Group: Bug => Enhancement ___ Follow-up Comment #1: Hm. I'm not sure that there's anywhere in the make manual that says or implies that simply becaus

[bug #15968] make fails trying to stat a .PHONY target: p:foo

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15968> Summary: make fails trying to stat a .PHONY target: p\:foo Project: make Submitted by: gkeranen Submitted on: Fri 03/03/06 at 01:31 Severity:

Re: attempting to make gnu make fails on FreeBSD 5.0 installation

See this thread on the bug-make mailing list archives: http://www.mail-archive.com/bug-make%40gnu.org/msg02495.html -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org

attempting to make gnu make fails on FreeBSD 5.0 installation

Didn't know if this was news to anyone, or if I'm doing something stupid.. Output of configure and make attached. > freebsd# ./configure > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... no > checking for mawk.

Re: make fails

This isn't a problem with GNU make. Make just runs your compiler with whatever arguments the makefile says, and it's doing that correctly as far as I can tell. If the compiler can't compile the code, then that's a matter for discussion with the authors of the makefile or the code or, remotely po

make fails

Hi, I'm running Linux 2.2.4 kernel, tried mnogosearch-3.1.17.tar.gz mnogosearch-3.2.0.b0.tar.gz can't get either one to work GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i386-redhat-linux-gnu Copyright (C) 1988, 89, 90, 91, 92

Re: Bug#72802: make fails to correctly echo commands

%% Manoj Srivastava <[EMAIL PROTECTED]> writes: ms> make 3.79.1 is not correctly echoing commands when they occur in ms> canned command sequences. This problem can be fixed with the following patch. This will be included in the next release of GNU make. Thanks for your bug report.

Re: Bug#72802: make fails to correctly echo commands

%% Manoj Srivastava <[EMAIL PROTECTED]> writes: ms> [Please retain the CC to [EMAIL PROTECTED] so ms> that the Debian Bug Tracking system can record your input] ms> make 3.79.1 is not correctly echoing commands when they occur in ms> canned command sequences. I

Re: Bug#72802: make fails to correctly echo commands

Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian Bug Tracking system can record your input] make 3.79.1 is not correctly echoing commands when they occur in canned command sequences. Since this is the latest version of make, I have downgraded to the vers

make fails to correctly echo commands

Package: make Version: 3.79.1 make (in Debian 2.2) is not correctly echoing commands when they occur in canned command sequences. Since this is the latest version of make, I have downgraded to the version from Debian 2.1 (make 3.77), which never gave me any problems. The makefile below demonstr