Phony targets not being made

r2 doing rr1-sim all done Is this a bug or is there anything wrong in the Makefile? Regards Christian Paulsen

[bug #25412] mingw32-make crashes when double quotes at end of PATH

URL: Summary: mingw32-make crashes when double quotes at end of PATH Project: make Submitted by: chehrlic Submitted on: Mo 26 Jan 2009 17:16:10 GMT Severity: 3 - Normal

[bug #26864] make -j2 fails to rebuild intermediate file

Follow-up Comment #3, bug #26864 (project make): I have noticed the same thing, it seems to fix itself with the following pa (file #18949) ___ Additional Item Attachment: File name: make.patch Size:0 KB _

[bug #29074] -include target fails to issue Error in 3.81

Follow-up Comment #5, bug #29074 (project make): I agree with Hack Lee. There was a bug before 3.81. You wouldn't want make to fall over on an -include $(sources:%.c=%.d) in the Makefile because of a source error when you're actually running make clean The behavior of GNUmake 3.81 is correct.

[bug #40227] Various fixes for MSVC build of 4.0

URL: Summary: Various fixes for MSVC build of 4.0 Project: make Submitted by: cboos Submitted on: Wed 09 Oct 2013 11:42:35 PM GMT Severity: 3 - Normal Item Group: Build/I

[bug #40227] Various fixes for MSVC build of 4.0

Additional Item Attachment, bug #40227 (project make): File name: 0001-Fix-MSVC-build-using-the-NMakefile.patch Size:1 KB ___ Reply to this item at: ___

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #1, bug #40226 (project make): Second thought... I see now where the bug is coming from. Some use cases for the stringlist imply it's handled as a null-terminated array: for (pp=output_sync_option->list; *pp; ++pp) Some others iterate up to idx: for (idx = 1; idx <

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #3, bug #40226 (project make): Well, the symptom can even be reproduced without a Makefile... $ /C/Workspace/src/git/make/WinDebug/make -Otarget -f no-Makefile make: no-Makefile: No such file or directory make: *** internal error: multiple --sync-mutex options. Stop. The rea

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #9, bug #40226 (project make): Eli, it looks like the problem is triggered as soon as you have some output generated during the `read_all_makefiles ()` phase, as it causes a call to `prepare_mutex_handle_string ()`. And after reading the Makefiles, `main ()` calls `decode_env

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #10, bug #40226 (project make): Actually, this issue can also be reproduced with a x64 build done using MinGW (from http://mingw-w64.sourceforge.net/). c:Workspacesrcgitmake>gnumake.exe -f Makefile.bug -Otarget Hello gnumake.exe: *** internal error: multiple --sync-mutex option

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #3, bug #40227 (project make): Actually, it seems that this output problem also affects MinGW builds, not just MSVC builds. The patch 0004-MinGW-also-needs-the-msc_vsnprintf-replacement-for-v.patch fixed it for me. As I don't have Cygwin I couldn't verify if the WINDOWS32 def

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #6, bug #40227 (project make): I found the _vsnprintf_s declaration in my MinGW installation: .../mingw64/x86_64-w64-mingw32/include/sec_api/stdio_s.h And this gets included from . I suppose this must be a relatively recent addition, as I installed that version today (major.min

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #9, bug #40227 (project make): > (Btw, what is gnumake32.exe in your case, and how is it different from gnumake64.exe?) Sorry if that wasn't clear: gnumake32.exe was built with the 32-bits toolchain from MinGW-w64, and gnumake64.exe was built with the 64-bits toolchain from MinG

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #10, bug #40227 (project make): ... and I just debugged the make built with the MinGW-w64 toolchain for x64 and *without* the -D__USE_MINGW_ANSI_STDIO=1 flag, the problem is indeed that vsnprintf returns -1 when the fmtbuf is not large enough. Also, I must have forgotten to rev

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #12, bug #40227 (project make): Yes, that would work, but the #define has to be added much earlier, as even makeint.h includes stdio.h... See 0004c-Ask-MinGW-w64-to-use-ANSI-style-vsnprintf.patch (file #29377) ___ Additi

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #13, bug #40227 (project make): I tested that patch (file #29377) with the mingw.org toolchain (gcc 4.4.0) and make still works after that, so I think it's safe to apply, provided this doesn't disturb the cygwin build... I also looked at mingw.org's mingw32/include/stdio.h and

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #15, bug #40227 (project make): As requested, 3 debugging sessions that recap the whole problem with vsnprintf for MinGW-w64. (file #29378) ___ Additional Item Attachment: File name: gdb-trace-vsnprintf.txtSize:13

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #18, bug #40227 (project make): Yep, patch in file #29381 works for me as well (tested with both x32 and x64 toolchains of MinGW-w64). Thanks! Googling shows that lots of projects stumble upon this issue. MinGW-w64 chose to be compatible with the behavior of the MS API by

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #20, bug #40227 (project make): Thanks for applying! As for the /STACK patch, the issue I got in my early tries was an exception with code 0xC0FD (STATUS_STACK_OVERFLOW). Now my problem is that I can't reproduce it anymore, even with x64 bits and the "default" /STACK. But g

make doesn't complain if target cannot be built

if (!rebuilding_makefiles || !file->dontcare) complain (file); file->update_status = us_failed; } } else ---snap--- regards Christian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Re: make doesn't complain if target cannot be built

Am Montag, 13. Januar 2014, 17:20:43 schrieb Paul Smith: > On Mon, 2014-01-13 at 22:23 +0100, Christian Eggers wrote: > > In Makefile 2 my intention was to state that foo.o depends on some > > generated header which must be generated first (might be in another > > rule).

Re: make doesn't complain if target cannot be built

s the case, then it can be slightly better to use an order-only > prerequisite for the generated file, ala: > $(OBJS): | generated.h > That guarantees the generated.h file will > exist before trying to build any objects, but if generated.h gets rebuilt, > only the ob

Re: make doesn't complain if target cannot be built

.c) $(OUTPUT_OPTION) $< generated.h: generated.x touch $(@) clean: $(RM) $(OBJS) $(OBJS:%=%.d) generated.h -include $(OBJS:%=%.d) ---EOF--- This avoids $(OBJS) to become a target (unless the dependency files are generated). This seems to work correctly for all cases I tested If

[bug #41730] Make doesn't show text for error messages when using the Microsoft C runtime

Follow-up Comment #1, bug #41730 (project make): Duplicate of bug #40227 which is already fixed in git. You'll soon realize that there are some other issues with stock 4.0 when it's built with msvc, so better go with the latest in git ;-) _

GNU make 4.1 features/archives test failure on OpenBSD

t: lib(foo) -(%): %.vhd ; @cd $(DIR) && touch $(*F) && $(AR) $(ARFLAGS) $@ $(*F) >/dev/null 2>&1 && rm $(*F) +(%): %.vhd ; @cd $(DIR) && echo foo >$(*F) && $(AR) $(ARFLAGS) $@ $(*F) >/dev/null 2>&1 && rm

[bug #43887] shell function blocks for x64 builds with MSVC compiler

URL: Summary: shell function blocks for x64 builds with MSVC compiler Project: make Submitted by: cboos Submitted on: Thu 25 Dec 2014 05:55:11 PM GMT Severity: 3 - Normal

[bug #44308] combination of $(call ...) and $(value ...) functions

Follow-up Comment #4, bug #44308 (project make): Your example reminded me similar constructions I use a lot in my own Makefiles. I use a technique which I call the eval/value style which allows me to generate parametric Make code without having to deal with annoying levels of $ quoting. Here's h

[bug #46077] SHELL process handling does not work under Windows 10 in x64 build -> endless waiting

Follow-up Comment #2, bug #46077 (project make): Eli, I just saw that make-4.1-2-w32-src.zip from your ezwinports doesn't have that fix. Any chance for a 4.2pre build? ___ Reply to this item at: ___

[bug #46077] SHELL process handling does not work under Windows 10 in x64 build -> endless waiting

Follow-up Comment #4, bug #46077 (project make): Oh right, #43887 was indeed about a 64-bits (msvc) build. As sometimes my ez-make-4.1 builds hang with -j, I thought it could be because of this reason... but it could well be something else. I'll try to have a closer look by rebuilding 4.1-2 32-b

Nonexistent phony prerequisite

complains: $ make make: don't know how to make phony (prerequisite of: foo) -- Christian "naddy" Weisgerber na...@mips.inka.de ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

make says that file does not exist even if it just built it a few lines before?

ectory and type make all and the problem should appear. if you type make all again the project should build correctly. this archive also contains a make.log file in the src directory from my build. many thanks for any comments! -- MfG, Christian Schuhegger makeproblem.tar.bz2 Description: Binary data

make 3.80 on Ultrix 4.3

ake[2]: Leaving directory `/users/make-3.80' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/users/make-3.80' make: *** [all] Error 2 ds5000:/users/make-3.80 ==> with best regards Christian Krackowizer Schuler Business Solutions GmbH Jakob-Haringer-Strasse 6 A-5020

make check for 3.80

THREE.inc + ONE.inc TWO.inc ONE TWO + THREE success and DEC OSF 3.2C *** work/functions/eval.baseWed Jul 16 15:15:49 2003 --- work/functions/eval.log Wed Jul 16 15:15:49 2003 *** *** 1,2 ! AA BA --- 1,2 ! A BA with best regards Christian Krackowizer Schule

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

Follow-up Comment #8, bug #56449 (project make): [comment #5 comment #5:] > Sorry, I think there's some confusion. All this patch does is detect if we see a % in the command line and if so we do not take the fast path: instead we take the slow path and invoke command.com. > > So we're not trying

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

Follow-up Comment #9, bug #56449 (project make): [comment #6 comment #6:] > But the result is wrong when %..% doesn't specify a known variable, most probably because we invoke the command through a batch file. The question may be, which of both results is the correct one. So if cmd.exe has someth

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

Follow-up Comment #7, bug #56449 (project make): Hi, I'm the original author of this bug. It's some time ago I wrote this, so maybe I've forgotten some details... [comment #2 comment #2:] > I see that this bug was fixed and closed, but looking at the result, I'm not sure the fix is correct. If I

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

Follow-up Comment #12, bug #56449 (project make): [comment #10 comment #10:] > GNU Make emulates the behavior of the shell as if the user typed the commands at the shell's prompt. It is true that you need to double the % characters in batch files, but GNU Make doesn't behave like batch files do.

output-sync test mistake?

GNU make 4.3 There is some suspicious code in tests/scripts/features/output-sync that looks like a copy-and-paste error. Note that changing it also breaks one of the tests run there because the output order changes. Is this an actual mistake? Maybe I should try to understand the logic of the te

output-sync test can fail due to race condition

eeds additional sequencing. -- Christian "naddy" Weisgerber na...@mips.inka.de work.tgz Description: application/gtar-compressed

Suggestion: Modernization of the include path

that condition. Rationale for b): INCLUDE_DIRS+=${HOME}/.local/include has no effect and does not print any error message, which is not friendly towards users of make. Something should either work, or when it doesn't, it should print an error message. Best regards, -- Christian Hujer CEO/CTO Nelkind

Re: Parallel job instance identifiers?

rts conflict trouble. Christian On Fri, Aug 13, 2021, 18:44 Howard Chu via Bug reports and discussion for GNU make wrote: > In my original jobserver implementation, I filled the job pipe with > up to 256 bytes, numbers from 0-255. The idea being that then make > could distinguish eac

Re: Parallel job instance identifiers?

n-a-makefile/52159940#52159940 I hope that this helps you and provides you with a pathway solution that allows you even more control without accidental coupling to internal features of make. And while I think that using make is great, this solution would even work if you use something else than make.

RE: GNUmake v4.4 port on Solaris with gcc 9.5.0

| ^~ concat-filename.c:69:7: warning: incompatible implicit declaration of built-in function 'stpcpy' -Original Message- From: Christian Jullien [mailto:eli...@orange.fr] Sent: Thursday, November 03, 2022 06:51 To: psm...@gnu.org; jull...@eligis.com; make-...@gnu.