[bug #66268] Messed up error message about a failure to remove an intermediate file.

Update of bug #66268 (group make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Fixed Release:

[bug #66268] Messed up error message about a failure to remove an intermediate file.

Additional Item Attachment, bug #66268 (group make): File name: sv66268_intermfile_removal_error_msg.diff Size: 2KiB AGPL NOTICE These attachments are served by Savane. You can download the corr

[bug #66268] Messed up error message about a failure to remove an intermediate file.

Follow-up Comment #1, bug #66268 (group make): Messed up error message about a failure to remove an intermediate file. $ cat makefile all: hello.x %.x: b/%.q; $(info $@ from $<) b/%.q:; mkdir b; touch $@; chmod -w b $ make mkdir b; touch b/hello.q; chmod -w b hello.x from b/hello.q r

[bug #66268] Messed up error message about a failure to remove an intermediate file.

URL: <https://savannah.gnu.org/bugs/?66268> Summary: Messed up error message about a failure to remove an intermediate file. Group: make Submitter: dgoncharov Submitted: Sat 28 Sep 2024 12:38:31 PM UTC Sever

Re: Treat "Circular dependency...dropped" as a hard error instead?

On Mon, 2024-05-13 at 22:05 -0400, Dmitry Goncharov wrote: > On Wed, May 8, 2024 at 2:04 PM JZB wrote: > > > > I have a GNU make-based build system wherein I would like for > > any/all > > GNU make-detected circular dependencies to be treated as a hard > > e

Re: Treat "Circular dependency...dropped" as a hard error instead?

On 5/13/24 21:05, Dmitry Goncharov wrote: On Wed, May 8, 2024 at 2:04 PM JZB wrote: I have a GNU make-based build system wherein I would like for any/all GNU make-detected circular dependencies to be treated as a hard error, i.e., fail [immediately], rather than a "dropped and we

Re: Treat "Circular dependency...dropped" as a hard error instead?

On Wed, May 8, 2024 at 2:04 PM JZB wrote: > > I have a GNU make-based build system wherein I would like for any/all > GNU make-detected circular dependencies to be treated as a hard error, > i.e., fail [immediately], rather than a "dropped and we go on without > it..."

Re: Treat "Circular dependency...dropped" as a hard error instead?

On 5/11/24 06:11, Dmitry Goncharov wrote: On Wed, May 8, 2024 at 2:04 PM JZB wrote: ... perhaps a command line option or a ".CIRCULARERROR:" rule or some way to allow this to be turned on by those who need it? There is currently no mechanism (option or otherwise) to fail on a circular depende

Re: Treat "Circular dependency...dropped" as a hard error instead?

On Wed, May 8, 2024 at 2:04 PM JZB wrote: >... perhaps a command line option or a ".CIRCULARERROR:" rule > or some way to allow this to be turned on by those who need it? There is currently no mechanism (option or otherwise) to fail on a circular dependency. On top of that, there are situations w

Treat "Circular dependency...dropped" as a hard error instead?

I have a GNU make-based build system wherein I would like for any/all GNU make-detected circular dependencies to be treated as a hard error, i.e., fail [immediately], rather than a "dropped and we go on without it..." situation. Is there a way to do this already? I do NOT suggest

[bug #64402] error parsing functions in braces inside ifeq, ifneq

de-effect, only parens or braces which are part of a variable reference are counted, so if you had something like this: ifeq ((foo,bar),) that is now a syntax error (of course it's find if you have a variable reference that _

[bug #64402] error parsing functions in braces inside ifeq, ifneq

URL: <https://savannah.gnu.org/bugs/?64402> Summary: error parsing functions in braces inside ifeq, ifneq Group: make Submitter: None Submitted: Mon 10 Jul 2023 11:40:55 AM UTC Severity: 3 -

[bug #63984] Error 2133

Update of bug #63984 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: There's no information

[bug #63984] Error 2133

URL: <https://savannah.gnu.org/bugs/?63984> Summary: Error 2133 Group: make Submitter: None Submitted: Fri 31 Mar 2023 01:26:38 PM UTC Severity: 3 - Normal Item Group: Bug

Re: A spell error in pdf manual

On Fri, 2023-02-03 at 21:51 +0800, 毛欣宇 wrote: > The second paragraph begins "If an expression matches multiple files > than the results will be sorted",it should be "then" rather than > "than"? Fixed; thank you!

A spell error in pdf manual

In chapter 4 4.3 Using Wildcard Characters in File Names The second paragraph begins "If an expression matches multiple files than the results will be sorted",it should be "then" rather than "than"?

[PATCH 3/8] Fix assignment of read-only location error on OS/2

* src/job.c (construct_command_argv_internal) [__EMX__]: Use a buffer allocated in a stack. --- src/job.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/job.c b/src/job.c index b78f279c..aa848f0e 100644 --- a/src/job.c +++ b/src/job.c @@ -3226,7 +3226,11 @@ construct_

Re: [PATCH 1/2] Fix duplicated __strchrnul() declaration error on OS/2 kLIBC

Hi/2. Paul Smith wrote: > On Wed, 2022-11-09 at 22:45 +0900, KO Myung-Hun wrote: >> OS/2 kLIBC has __strchrnul(). But HAVE___STRCHRNUL is undefined. >> 'static' declarion of __strchrnul() causes an error with gcc4 because >> OS/2 kLIBC declares __strchrnul() as p

Re: [PATCH 1/2] Fix duplicated __strchrnul() declaration error on OS/2 kLIBC

On Wed, 2022-11-09 at 22:45 +0900, KO Myung-Hun wrote: > OS/2 kLIBC has __strchrnul(). But HAVE___STRCHRNUL is undefined. > 'static' declarion of __strchrnul() causes an error with gcc4 because > OS/2 kLIBC declares __strchrnul() as public. I assume kLIBC is a libc implementa

[PATCH 1/2] Fix duplicated __strchrnul() declaration error on OS/2 kLIBC

OS/2 kLIBC has __strchrnul(). But HAVE___STRCHRNUL is undefined. 'static' declarion of __strchrnul() causes an error with gcc4 because OS/2 kLIBC declares __strchrnul() as public. - gcc -DHAVE_CONFIG_H -I. -I../src -D__ST_MT_ERRNO__ -Wno-cast-qual -Wno-conversion -Wno-float-

[PATCH 2/2] Fix assignment of read-only location error OS/2

se.Po src/job.c: In function 'construct_command_argv_internal': src/job.c:3229:21: error: assignment of read-only location '*shellflags' 3229 | shellflags[0] = '/'; /* "/c" */ | ^ - --- src/job.c | 8 +++- 1 file c

[bug #63329] readdir() error in 4.4 on Solaris 8

Update of bug #63329 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: Looks like this is an

[bug #63330] readdir() error in 4.4 on Solaris 8

Update of bug #63330 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #12: Ah! Good news! Than

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #11, bug #63330 (project make): I was working from a git checkout and it appears that it somehow got into a strange state. A build of a fresh download of the 4.4 tarball is fine. My apologies for the confusion, this can be closed. _

Re: [bug #63330] readdir() error in 4.4 on Solaris 8

good > working make-4.3 config.log and config.status and this one that fails? > > In regards to the error see > https://docs.oracle.com/cd/E19455-01/806-1075/msgs-2215/index.html If I recall correctly, Sun recommends building 64-bit binaries on 64-bit OSes, but AutoTools still defau

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #10, bug #63330 (project make): Wow I'm REALLY confused. I've examined the config.log file you provided and I can't make heads or tails of it. There is no reference anywhere in that file, to checking for largefile support. This likely explains why it's not enabled on this syst

[bug #63330] readdir() error in 4.4 on Solaris 8

s for _FILE_OFFSET_BITS in your config.log. Does make work if you build 64 bit or set -D_FILE_OFFSET_BITS=64? What is the difference, in regards to large file support, between your good working make-4.3 config.log and config.status and this one that fails? In regards to the error see

Re: [bug #63330] readdir() error in 4.4 on Solaris 8

On Tue, Nov 8, 2022 at 8:16 AM anonymous wrote: > > Follow-up Comment #8, bug #63330 (project make): > > Just checked and this also affects Solaris 10. The issue looks identical, let > me know if you want details from that system. For testing, gcc210 at the Compile Farm is Solaris 10. See https:

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #8, bug #63330 (project make): Just checked and this also affects Solaris 10. The issue looks identical, let me know if you want details from that system. ___ Reply to this item at:

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #7, bug #63330 (project make): Oh and yes, 4.3 works just fine on NFS mounts. It's what I've been using to build 4.4. The NFS mount is definitely over 4GB but this is the first time I've run into issues with that. ___ R

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #6, bug #63330 (project make): I definitely don't expect everything to work perfectly on a system this old, and if it does turn out to be a Solaris bug I'll certainly find a way to deal with it locally. That being said I find that compiling on these older systems sometimes turns

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #5, bug #63330 (project make): That's certainly disturbing and I would very much like to figure out what's wrong. Just to be sure I built and ran the GNU Make regression tests on an NFS-mounted partition and it worked fine, but this was a GNU/Linux client and a NetApp NFS server

Re: [bug #63330] readdir() error in 4.4 on Solaris 8

Is make being built with -D_FILE_OFFSET_BITS=64 to use the large-file APIs? If not, then maybe the problem is an inode number that doesn't fit in the old 32-bit ino_t that some struct dirent's were stuck with. Check the output of "ls -l -i" (note the -i option!) to see if there's an inode number

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #4, bug #63330 (project make): It looks like this is somehow related to NFS. I was running the newly-generated make in the root of the source tree, and on an NFS mounted directory it fails immediately. If I copy the tree to a local directory I have no problems. __

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #3, bug #63330 (project make): It's very strange because the code in 4.4 dir.c was changed in many places (to introduce directory cache invalidation) but this specific code related to readdir() is the same as in 4.3. I think we will need to either get a repro case (even if it on

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #2, bug #63330 (project make): Oh, actually that can't be it. I forgot that ENULLLOOP() sets errno=0 before it tries the command. Hm. Well, POSIX does allow EOVERFLOW to be returned by readdir() (that's the error you see). So maybe there's something about the

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #1, bug #63330 (project make): Hm. Maybe on Solaris readdir() doesn't reset errno? In src/dir.c you'll find this code: ENULLLOOP (d, readdir (dir->dirstream)); if (d == 0) { if (errno) pfatal_with_name ("INTERNAL: readdir");

[bug #63330] readdir() error in 4.4 on Solaris 8

URL: <https://savannah.gnu.org/bugs/?63330> Summary: readdir() error in 4.4 on Solaris 8 Project: make Submitter: None Submitted: Mon 07 Nov 2022 03:37:45 PM UTC Severity: 3 - Normal Item Grou

[bug #63243] Fix a race between sigterm and make writing its error message.

Follow-up Comment #3, bug #63243 (project make): Probably in the next release when I fix signal handling, this will not be needed anymore. ___ Reply to this item at: __

[bug #63236] Fix getloadavg related error message.

Update of bug #63236 (project make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => POSIX-Based Fixed Release:

[bug #63243] Fix a race between sigterm and make writing its error message.

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

[bug #63243] Fix a race between sigterm and make writing its error message.

Additional Item Attachment, bug #63243 (project make): File name: sv63243.diff Size:2 KB ___ Reply to this item at:

[bug #63243] Fix a race between sigterm and make writing its error message.

Follow-up Comment #1, bug #63243 (project make): Tests in temp_stdin and output-sync send sigterm to kill make. There is a race here between sigterm and make writing to the log file. This races causes the tests to fail occasionally. The original bug report and a patch provided by Frank Heckenbach

[bug #63243] Fix a race between sigterm and make writing its error message.

URL: <https://savannah.gnu.org/bugs/?63243> Summary: Fix a race between sigterm and make writing its error message. Project: make Submitter: dgoncharov Submitted: Thu 20 Oct 2022 12:35:26 AM UTC Sever

[bug #63236] Fix getloadavg related error message.

Additional Item Attachment, bug #63236 (project make): File name: sv63236.diff Size:0 KB ___ Reply to this item at:

[bug #63236] Fix getloadavg related error message.

Follow-up Comment #1, bug #63236 (project make): On aix (actually possible on any system) getloadavg fails and keeps errno intact. This results in a bogus error message from make. The patch resets errno before calling getloadavg. $ cat makefile MAKEFLAGS:=-Rr all: 1.x 2.x 3.x 4.x %.x:; sleep 10

[bug #63236] Fix getloadavg related error message.

URL: <https://savannah.gnu.org/bugs/?63236> Summary: Fix getloadavg related error message. Project: make Submitter: dgoncharov Submitted: Wed 19 Oct 2022 01:32:41 AM UTC Severity: 3 - Normal Item

Re: shell function: confusing error when shebang incorrect

ceptions, therefore, when I see an error, I fully expect it to be coming from the shell. There's some difference IMHO between a recipe invocation, which only implicitly invokes the shell (leaving aside the fact that POSIX says it does so), and a direct, specific request to invoke the shell vi

Re: shell function: confusing error when shebang incorrect

examine the interpreter path to determine its status. It could be done but it's not pretty; also see below. > How about this then: try to do the optimisation, but if `execve` > fails (for whatever reason), silently fallback to calling the shell > and letting it report the error?

Re: shell function: confusing error when shebang incorrect

On Sun, Oct 9, 2022 at 11:57 AM wrote: > The interpretation of a bad shebang is platform-specific and has no single > consistent interpretation. Some platforms will report EPERM, EACCESS, or > ENOENT. The error is not necessarily under bash or zsh control but could come > f

RE: shell function: confusing error when shebang incorrect

#!/bin/ohno >echo hi > >$ make >make: ./foo.sh: No such file or directory >make: *** No targets. Stop. > >$ ./foo.sh >zsh: ./foo.sh: bad interpreter: /bin/ohno: no such file or directory ``` > >The “no such file or directory” error from Make is very confusing and >une

shell function: confusing error when shebang incorrect

targets. Stop. $ ./foo.sh zsh: ./foo.sh: bad interpreter: /bin/ohno: no such file or directory ``` The “no such file or directory” error from Make is very confusing and unexpected in this situation, especially given that it is not the error that the shell would return. The reason for it is that, while

Re: [bug #63037] make check: 3 failures and error from "check-regression"

Thanks for fixing the three failures in the check target. The case "chmod -x" is explained on the "info chmod" first page, second paragraph above the first option '-c'.

[bug #63037] make check: 3 failures and error from "check-regression"

ment #2: Fixed, I think. I'm not sure I fixed the temp_stdin error; I can't understand why the chmod -x failed with that strange message. I can only assume that you're running in some environment where for some reason the test is not allowed to change group permissions on files it just

[bug #63037] make check: 3 failures and error from "check-regression"

Follow-up Comment #1, bug #63037 (project make): The load error is simple enough to fix: just need to update the code. The temp_stdin error is definitely annoying. It's an unfortunate fact that known-good-output checking where the output comes from system tools is difficult to work with.

[bug #63037] make check: 3 failures and error from "check-regression"

URL: <https://savannah.gnu.org/bugs/?63037> Summary: make check: 3 failures and error from "check-regression" Project: make Submitter: bjarniig Submitted: Fri 09 Sep 2022 12:15:14 AM UTC Seve

Re: False positive "doesn't match the target pattern" error

Hi, Masahiro Yamada wrote in his original bug report: > ./foo.x: %/foo.x: %/foo.z > cp $< $@ This is not make(1) syntax. POSIX does not define "%", nor multiple colons on the same line, and i fail to see right now how any similar problem might occur with POSIX make(1) - of course, i might

Re: False positive "doesn't match the target pattern" error

Hi David, Ingo, For others starting to read this thread now, it started here: On 8/22/22 16:46, David A. Wheeler wrote: On Aug 22, 2022, at 12:02 AM, Alejandro Colomar wrote: Hi David, On 8/22/22 04:45, David A. Wheeler w

Re: False positive "doesn't match the target pattern" error

> On Aug 22, 2022, at 12:02 AM, Alejandro Colomar > wrote: > > Hi David, > > On 8/22/22 04:45, David A. Wheeler wrote: >>> On Aug 20, 2022, at 11:35 AM, Alejandro Colomar >>> wrote: >>> I'd say there is: make(1) treats file names as text strings, not really >>> file names, for most of it

Re: False positive "doesn't match the target pattern" error

Hi David, On 8/22/22 04:45, David A. Wheeler wrote: On Aug 20, 2022, at 11:35 AM, Alejandro Colomar wrote: I'd say there is: make(1) treats file names as text strings, not really file names, for most of its operations. As an example, foo/ and foo/. are different targets. I don't see why

Re: False positive "doesn't match the target pattern" error

> On Aug 20, 2022, at 11:35 AM, Alejandro Colomar > wrote: > I'd say there is: make(1) treats file names as text strings, not really file > names, for most of its operations. As an example, foo/ and foo/. are > different targets. I don't see why ./bar and bar should be the same. > Consi

Re: False positive "doesn't match the target pattern" error

Hi Dmitry On 8/21/22 05:52, Dmitry Goncharov wrote: On Sat, Aug 20, 2022 at 8:28 PM Masahiro Yamada wrote: build-dirs := . drivers sound net virt arch/x86/pci arch/x86/power lib arch/x86/lib subdir-modorder := $(addsuffix /.modules.order, $(build-dirs)) $(sort $(subdir-modorder)): %/.modules.o

Re: False positive "doesn't match the target pattern" error

On Sat, Aug 20, 2022 at 8:28 PM Masahiro Yamada wrote: > build-dirs := . drivers sound net virt arch/x86/pci arch/x86/power lib > arch/x86/lib > subdir-modorder := $(addsuffix /.modules.order, $(build-dirs)) > $(sort $(subdir-modorder)): %/.modules.order: % Can you remove . from build-dirs and ad

Re: False positive "doesn't match the target pattern" error

On Sun, Aug 21, 2022 at 12:48 AM Dmitry Goncharov wrote: > > On Sat, Aug 20, 2022 at 11:36 AM Alejandro Colomar > wrote: > > Why does make(1) need to special-case a leading ./ ? > > If your makefile has a rule like > foo.x: foo.z; cp $< $@ > then make foo.x and make ./foo.x both produce the same

Re: False positive "doesn't match the target pattern" error

On Sun, Aug 21, 2022 at 12:32 AM Dmitry Goncharov wrote: > > On Sat, Aug 20, 2022 at 5:52 AM Masahiro Yamada wrote: > > I appreciate GNU Make normalize the path > > by removing "./" > > > > This is helpful in some cases, but I think it is a bad side-effect > > in this case. > > Is there a reason

Re: False positive "doesn't match the target pattern" error

On Sat, Aug 20, 2022 at 11:36 AM Alejandro Colomar wrote: > Why does make(1) need to special-case a leading ./ ? If your makefile has a rule like foo.x: foo.z; cp $< $@ then make foo.x and make ./foo.x both produce the same file. regards, Dmitry

Re: False positive "doesn't match the target pattern" error

Hi Dmitry, On 8/20/22 17:32, Dmitry Goncharov wrote: On Sat, Aug 20, 2022 at 5:52 AM Masahiro Yamada wrote: I appreciate GNU Make normalize the path by removing "./" This is helpful in some cases, but I think it is a bad side-effect in this case. Is there a reason to treat './foo.x' as diff

Re: False positive "doesn't match the target pattern" error

On Sat, Aug 20, 2022 at 5:52 AM Masahiro Yamada wrote: > I appreciate GNU Make normalize the path > by removing "./" > > This is helpful in some cases, but I think it is a bad side-effect > in this case. Is there a reason to treat './foo.x' as different from 'foo.x'? > If this is a bug, I can f

False positive "doesn't match the target pattern" error

more information. make: *** [Makefile:3: foo.x] Error 1 I believe "./foo.x" matches the target pattern "%/foo.x" Am I wrong? I appreciate GNU Make normalize the path by removing "./" This is helpful in some cases, but I think it is a bad side-effect in this ca

Re: Bug with collect2.exe: error: ld returned 1 exit status make: *** [Makefile:2: all] Error 1

On Tue, 2022-08-09 at 17:38 +0200, Ibrahim Salma wrote: > Hi, i am having problem with makefile or make command can you please > help me it's giving me an error message like this: > > collect2.exe: error: ld returned 1 exit status > make: *** [Makefile:2: all] Error 1 T

Bug with collect2.exe: error: ld returned 1 exit status make: *** [Makefile:2: all] Error 1

Hi, i am having problem with makefile or make command can you please help me it's giving me an error message like this: collect2.exe: error: ld returned 1 exit status make: *** [Makefile:2: all] Error 1 This is the code in the Makefile: all: g++ -I src/include -L src/lib -o main mai

[bug #62858] error: too few arguments to function ‘find_in_given_path’

Follow-up Comment #4, bug #62858 (project make): IMO as I said earlier if you want the official 4.3 release it's best to just build it from the downloaded source, not from Git: it's much easier / more stable / more reliable. However, current gnulib does support setting a gnulib SHA reference that

[bug #62858] error: too few arguments to function ‘find_in_given_path’

Follow-up Comment #3, bug #62858 (project make): Just as @psmith pointed out, some functions in gnulib changed their signature, e.g: find_in_given_path(), In case if someone need to build 4.3 release from git repo, please try these steps: 1. In a dir: $dir1, $ git clone https://git.savannah.g

[bug #62858] error: too few arguments to function ‘find_in_given_path’

Follow-up Comment #2, bug #62858 (project make): [comment #1 comment #1:] ... > > If you want to build from Git, then make sure you have the latest version from Git. After checking, yeah, my repo is an old one, and I forget to pull. Thank you!

[bug #62858] error: too few arguments to function ‘find_in_given_path’

Update of bug #62858 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: This is not the code t

[bug #62858] error: too few arguments to function ‘find_in_given_path’

URL: <https://savannah.gnu.org/bugs/?62858> Summary: error: too few arguments to function ‘find_in_given_path’ Project: make Submitter: chenzero Submitted: Wed 03 Aug 2022 02:35:36 PM UTC Severity: 3 -

[bug #39146] Indicate error upon termination in case of parallel jobs

Follow-up Comment #1, bug #39146 (project make): I want to reinforce the need for a feature like this and suggest a slightly different output. Currently (GNU make 4.3), when run with -j[N], if there is an error, the output looks like this: $ make -j ... make: *** [Makefile:: ] Error make

[bug #62228] prerequisite based on input file created during processing not created, but no error

Follow-up Comment #2, bug #62228 (project make): thanks! ___ Reply to this item at: ___ Message sent via Savannah https://savannah.gnu.org/

[bug #62228] prerequisite based on input file created during processing not created, but no error

Update of bug #62228 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Make always parses all

Re: [bug #62228] prerequisite based on input file created during processing not created, but no error

$@ .PHONY: all setup processoutputs something clean all: setup something processoutputs allx: setup something1 processoutputs setup: @for dir in ${OUTDIR} ${INDIR}; do \ if [ ! -e $${dir} ]; then mkdir $${dir}; fi \ done @if [[ -f ${NEWIN} ]]; then \

Re: [bug #62228] prerequisite based on input file created during processing not created, but no error

Greg Minshall (30 March 2022 01:27) replied: > thanks very much for the reply. and, for the hints (on better use of > make functions). You're welcome. I do recommend reading the make info pages for the details more often than most developers seem to - most of the tools I've seen that claimed to b

Re: [bug #62228] prerequisite based on input file created during processing not created, but no error

Eddy, thanks very much for the reply. and, for the hints (on better use of make functions). >> something: >> @touch ${NEWIN} > It is generally good to let make know what files a rule creates, rather > than creating files as a side-effect of making a phony target. i guess this is the key.

Re: [bug #62228] prerequisite based on input file created during processing not created, but no error

Greg Minshall (29 March 2022 06:38) wrote: > hi. sorry. i'm not sure if this is a bug. I'm fairly sure it isn't. > (but, i'm guessing that dependencies are built when the makefile is read, then > not updated?) The assignment of variables happens when the Makefile is read, but there are two kin

[bug #62228] prerequisite based on input file created during processing not created, but no error

URL: <https://savannah.gnu.org/bugs/?62228> Summary: prerequisite based on input file created during processing not created, but no error Project: make Submitted by: minshall Submitted on: Tue 29 Mar 2022 04:38:56

[bug #61226] Missing included files that have rules don't show as an error

Follow-up Comment #11, bug #61226 (project make): In the abstract, it seems to me that if a user asks to include a file and that file doesn't exist, that the include should generate some kind of error. However, maybe you're right that if a rule exists that tells make how to build tha

[bug #61226] Missing included files that have rules don't show as an error

Follow-up Comment #10, bug #61226 (project make): [comment #9 comment #9:] > I will leave this issue open to think about how to best introduce a backward-incompatible change that might help in this situation. Do i understand it correctly, that as long as compatibility allows, you'd like make to f

[bug #61226] Missing included files that have rules don't show as an error

Update of bug #61226 (project make): Item Group: Bug => Enhancement Summary: A regression prevents generation of missing included dependency files. => Missing included files that have rules don't show

Re: Compilation error with GCC

x27; branch on commit c5d4b7b2f260c) and bootstrapped it with Gnulib (on commit 64f5221ef20ba) on Arch GNU/Linux and with GCC 11.1.0 and Glibc 2.33. The configuration went nicely, however, during the compilation it crashed with the attached error. Please let me know if any further information is necessary. Thank you, Mohammad

Re: Compilation error with GCC

On Sun, 2021-12-19 at 20:04 +0100, Jouke Witteveen wrote: > The patches "file #52422" and "file #52428" should resolve your > issues. I pushed these changes to Git.

Re: Compilation error with GCC

d bootstrapped it with Gnulib (on commit 64f5221ef20ba) on Arch > > > GNU/Linux and with GCC 11.1.0 and Glibc 2.33. > > > > > > The configuration went nicely, however, during the compilation it > > > crashed with the attached error. > > > > > > Please let me know if any further information is necessary. > > > > > > Thank you, > > > Mohammad > > > > > > >

Re: Compilation error with GCC

On Sun, Dec 19, 2021 at 1:51 PM Mohammad Akhlaghi wrote: > The configuration went nicely, however, during the compilation it > crashed with the attached error. i think, Jouke provided patches to workaround this warning. You can pass a flag to gcc to not treat warnings as errors. e.g.

Re: Compilation error with GCC

I just cloned Make (with the 'master' branch on commit c5d4b7b2f260c) > > and bootstrapped it with Gnulib (on commit 64f5221ef20ba) on Arch > > GNU/Linux and with GCC 11.1.0 and Glibc 2.33. > > > > The configuration went nicely, however, during the compil

Re: Compilation error with GCC

he 'master' branch on commit c5d4b7b2f260c) and bootstrapped it with Gnulib (on commit 64f5221ef20ba) on Arch GNU/Linux and with GCC 11.1.0 and Glibc 2.33. The configuration went nicely, however, during the compilation it crashed with the attached error. Please let me know if any fu

Compilation error with GCC

d with the attached error. Please let me know if any further information is necessary. Thank you, Mohammad Making all in lib make[1]: Entering directory '/home/mohammad/tmp/software/make/lib' rm -f alloca.h-t alloca.h && \ { echo '/* DO NOT EDIT! GENERATED

Re: Compilation error on master branch (Commit c5d4b7b)

On 10/3/21 23:38, Paul Smith wrote: On Sun, 2021-10-03 at 23:23 +0200, Mohammad Akhlaghi wrote: I then ran the standard './configure' and 'make' commands to build it, but the build failed with the attached error messages when building 'src/guile.c'. These e

Re: Compilation error on master branch (Commit c5d4b7b)

On Sun, 2021-10-03 at 23:23 +0200, Mohammad Akhlaghi wrote: > I then ran the standard './configure' and 'make' commands to build > it, but the build failed with the attached error messages when > building 'src/guile.c'. These errors appear to be coming fro

Compilation error on master branch (Commit c5d4b7b)

figure' and 'make' commands to build it, but the build failed with the attached error messages when building 'src/guile.c'. Just for completeness, I am using GCC 11.1.0, with GNU libc 2.33, on an Arch GNU/Linux distribution. Please let me know if anything else may be ne

Re: Makefile Error

ested. > > Best Regards, > Vignesh > > > On Fri, Jun 25, 2021 at 3:31 PM Pete Dietl wrote: >> >> Would need to see project.mk >> >> On Fri, Jun 25, 2021 at 12:16 AM Vignesh Chandrasekaran >> wrote: >>> >>> Dear Sir/Madam, >>&

Re: Makefile Error

Would need to see project.mk On Fri, Jun 25, 2021 at 12:16 AM Vignesh Chandrasekaran < vignesh.2...@gmail.com> wrote: > Dear Sir/Madam, > > I was recently trying to use make to compile my code and flash it into an > ESP32 chip when I ran into an error (please see attachment). &

Re: GNU Make documentation example error

on example error * EXTERNAL EMAIL * Dear GNU maintainers, I think there may be a mistake in the section “5.8 Defining Canned Recipes” of the GNU Make manual: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2Fsoftware%2Fmake%2Fmanual%2Fmake.html%23Canned-Recip

  1   2   3   4   5   6   7   8   >