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

: 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.org Subject: GNUmake v4.4 port on Solaris with gcc 9.5.0 Hi

Re: Parallel job instance identifiers?

hat 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. Q'aplah! On Sat, Aug 14, 2021 at 5:57

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 distingu

Suggestion: Modernization of the include path

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 Nelkinda Software

Phony targets not being made

or is there anything wrong in the Makefile? Regards Christian Paulsen

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

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

[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.

[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

[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

[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

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

[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

[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

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

URL: http://savannah.gnu.org/bugs/?43887 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

GNU make 4.1 features/archives test failure on OpenBSD

$(*F) +(%): %.vhd ; @cd $(DIR) echo foo $(*F) $(AR) $(ARFLAGS) $@ $(*F) /dev/null 21 rm $(*F) .PHONY: default !, '', ); --- -- Christian naddy Weisgerber na...@mips.inka.de ___ Bug-make mailing

[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 ;-)

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

the generated.h file will exist before trying to build any objects, but if generated.h gets rebuilt, only the objects that have real dependencies from the automated dependency tracking setup will get rebuilt. That makes sense. Philip Guenther regards Christian -- Registergericht / Register

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

for all cases I tested If interested, see attached tar archive and run run_tests.sh. thanks Christian make_missing_implicit.tar.gz Description: application/compressed-tar ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo

make doesn't complain if target cannot be built

); 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). But I didn't want to change

[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.txt

[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:Workspacesrcgitmakegnumake.exe -f Makefile.bug -Otarget Hello gnumake.exe: *** internal error: multiple --sync-mutex

[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

[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 stdio.h. I suppose this must be a relatively recent addition, as I installed that version today

[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

[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

[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) ___

[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 #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

[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

[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 #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 #25412] mingw32-make crashes when double quotes at end of PATH

URL: http://savannah.gnu.org/bugs/?25412 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

make 3.80 on Ultrix 4.3

: *** [all] Error 2 ds5000:/users/make-3.80 == with best regards Christian Krackowizer Schuler Business Solutions GmbH Jakob-Haringer-Strasse 6 A-5020 Salzburg Phone: +43(0)662/2282-0 FAX: +43(0)662/2282-9 e-Mail: [EMAIL PROTECTED] ___ Bug-make mailing

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

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