Re: [bug #66870] memory corruption

On Wed, 2025-03-05 at 18:23 -0500, Dmitry Goncharov wrote: > There is a buffer overflow when shellflags contains characters > special to shell, like =. > See https://savannah.gnu.org/bugs/?65588. I got really fed up with the current command line parser and I have a fully-rewritten version that is

Re: Bug in GNU make if -j used with very high values

On Wed, 2024-12-18 at 15:29 -0500, Dianne Skoll wrote: > On Debian GNU/Linux 12 with default settings, the command: > >    make -j 7 > > hangs. This is https://savannah.gnu.org/bugs/index.php?66499

Re: [bug #66499] Parameter for option -j seems not to be validated and can cause hangs

On Sun, 2024-12-01 at 17:12 +0100, Henrik Carlqvist wrote: > On Sun,  1 Dec 2024 09:10:04 -0500 (EST) > "Paul D. Smith" wrote: > > F_GETPIPE_SZ will work on Linux but it's not portable (not part of > > POSIX > > fcntl) > > Suggestion: Use F_GETPIPE_SZ as a limit when it does exist, if not, > use

Re: [bug #66499] Parameter for option -j seems not to be validated and can cause hangs

On Sun, 1 Dec 2024 09:10:04 -0500 (EST) "Paul D. Smith" wrote: > F_GETPIPE_SZ will work on Linux but it's not portable (not part of POSIX > fcntl) Suggestion: Use F_GETPIPE_SZ as a limit when it does exist, if not, use some arbitrary big value which usually will be "big enough with a margin". I

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

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

Re: [bug #65759] handling of "-" and "--" on command line

On Mon, 2024-05-20 at 07:25 +0200, Henrik Carlqvist wrote: > On Sun, 19 May 2024 18:02:45 -0400 (EDT) > > Many programs use a single dash to mean "read from stdin" but make > > doesn't > > do this. > > Yes, it does: > > -8< > nazgul:/tmp> make -f - Yes, if

Re: [bug #60736] Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps.

On 5/19/24 18:25, Paul D. Smith wrote: Follow-up Comment #6, bug #60736 (group make): I think that using a warn option is better than forcing this to always warn. But I still think that the warning makes global usage useless, and since there's no way to control warnings on a per-target basis (to

Re: [bug #65759] handling of "-" and "--" on command line

On Sun, 19 May 2024 18:02:45 -0400 (EDT) > Many programs use a single dash to mean "read from stdin" but make doesn't > do this. Yes, it does: -8< nazgul:/tmp> make -f - all: ; echo hello ** pressing ctrl-d on this next line ** echo hello hello nazgul:/tmp>

Re: [bug #65533] gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower

> ... remove all those .EXPORT_ALL_VARIABLES: settings. This is just a very bad idea. Sorry for the side-track but in my experience exporting *any* make variable is a bad idea. Where I work we maintain a "Make Bible" which says something to the effect that the only time it makes sense to export

Re: [bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

On Fri, Mar 29, 2024 at 2:15 PM Martin Dorey wrote: > > URL: > > > Summary: Werrors from intprops-internal.h with gcc 8.3.0 >Group: make >Submitter: mdorey >Submitted: Fri 29 Mar 2024 11:1

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

Hi Martin and Paul, Thanks for your detailed explanation. I have no further concerns now. Have a great day ahead! Best regards, Haoxin Paul Smith 于2024年1月21日周日 23:24写道： > On Sun, 2024-01-21 at 12:00 +0800, Haoxin Tu wrote: > > May I know if you are planning to propose a fix for it? I checked

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

On Sun, 2024-01-21 at 12:00 +0800, Haoxin Tu wrote: > May I know if you are planning to propose a fix for it? I checked the > implementations of other `make` versions a bit further, and as far as > I can tell, the issue exists from the older make-4.0.90 (2014-9-30) > to the newest version of make (

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

ly to save us from. From: bug-make-bounces+martin.dorey=hds@gnu.org on behalf of Haoxin Tu Sent: Saturday, January 20, 2024 20:03 To: Martin Dorey Cc: psm...@gnu.org ; bug-make@gnu.org Subject: Re: [bug #64551] Possible null pointer dereference on the fu

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

0';` >> >> >> There's a nice catch there - where, in that recursive failure, the >> writing of that terminator overflows a buffer that wasn't actually >> reallocated yet. >> >> -- >> *From:* Paul Smith &g

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

eallocated yet. > > -- > *From:* Paul Smith > *Sent:* Saturday, January 20, 2024 07:51 > *To:* Haoxin Tu ; Martin Dorey < > martin.do...@hitachivantara.com> > *Cc:* bug-make@gnu.org > *Subject:* Re: [bug #64551] Possible null pointer derefe

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

day, January 20, 2024 07:51 To: Haoxin Tu ; Martin Dorey Cc: bug-make@gnu.org Subject: Re: [bug #64551] Possible null pointer dereference on the function get_buffer * EXTERNAL EMAIL * On Sat, 2024-01-20 at 23:37 +0800, Haoxin Tu wrote: > But I don't understand why the second

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

On Sat, 2024-01-20 at 23:37 +0800, Haoxin Tu wrote: > But I don't understand why the second invocation of `xrealloc` can > not return zero, I apologize for any imprecise information I provided > in the previous emails. Because of what I said in my original reply: > the entire point of xrealloc is

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

> . > > -- > *From:* bug-make-bounces+martin.dorey=hds@gnu.org > on behalf of Haoxin Tu < > haoxi...@gmail.com> > *Sent:* Saturday, January 20, 2024 06:17 > *To:* Paul D. Smith > *Cc:* Paul D. Smith ; bo...@kolpackov.net < > bo...@k

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

t/?id=68be4f74fce91b76e5915449268d6b5eb687aab9. From: bug-make-bounces+martin.dorey=hds@gnu.org on behalf of Haoxin Tu Sent: Saturday, January 20, 2024 06:17 To: Paul D. Smith Cc: Paul D. Smith ; bo...@kolpackov.net ; bug-make@gnu.org Subject: Re: [bug #64551] Possible null po

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

Hi, Thank you so much for your time and reply. We understand that the entire point of `xrealloc` is never returning 0 to client users/developers who use this function. However, the issue we reported here happens when the `xrealloc` internally handles the returned 0 from `realloc` or `malloc` func

Re: [bug #64806] "invalid output sync mutex" on windows

> Date: Mon, 15 Jan 2024 12:37:42 -0500 > From: Ken Brown > > This is a long shot, but I had a problem a year ago with parallel make > on Cygwin occasionally hanging. The solution turned out to be to force > make's jobserver to use pipes instead of fifos. If you want to try > this, pass make

Re: [bug #64806] "invalid output sync mutex" on windows

This is a long shot, but I had a problem a year ago with parallel make on Cygwin occasionally hanging. The solution turned out to be to force make's jobserver to use pipes instead of fifos. If you want to try this, pass make the option '--jobserver-style=pipe'. Ken

Re: [bug #64571] Add option to print targets

* even on relatively ancient distro I could easily install it on Debian Wheezy (via wheezy-backports), a release from ten years ago. I can't see someone using the next version of Gnu Make and wanting cutting edge facilities for debugging their makefiles on such a crusty old thing. JSON fe

Re: Bug with $(info xxx) in 4.2.1

On Fri, Dec 8, 2023 at 7:38 PM Paul Smith wrote: > > In make it's fine to have a make line indented with a TAB, that is not > part of a recipe. If a line appears outside of the context of a rule, > then leading whitespace is ignored. There is a section in the documentation called "How Makefiles

Re: Bug with $(info xxx) in 4.2.1

On Thu, 2023-12-07 at 11:38 -0500, Dmitry Goncharov wrote: > On Tue, Dec 5, 2023 at 12:01 AM Aaron Williams > wrote: > > > What is happening is I will get the error: > > *** recipe commences before first target.  Stop. > > At the line with $(info xxx) unless I do not precede it with a tab. > > T

Re: Bug with $(info xxx) in 4.2.1

On Tue, Dec 5, 2023 at 12:01 AM Aaron Williams wrote: > What is happening is I will get the error: > *** recipe commences before first target. Stop. > At the line with $(info xxx) unless I do not precede it with a tab. This error is expected. A tab precedes a recipe. It does not matter what the

Re: [bug #64571] Add option to print targets

On Thu, 16 Nov 2023 at 09:11, Tim wrote: > Follow-up Comment #4, bug #64571 (project make): > > > > I'm just skeptical that this wouldn't degenerate into a morass of > conflicting requests for new features. > > Maybe. But this is clearly a highly demanded feature just for > auto-complete/dis

Re: [bug #64571] Add option to print targets

On Wed, Nov 1, 2023 at 10:26 AM Tim Murphy wrote: > Perhaps make could do with some sort of plugin mechanism? I know it has the > load keyword within makefiles but I'm not sure if functions have access to > enough global state to e.g. print out a list of targets. Currently there is no interfac

Re: [bug #64571] Add option to print targets

On Wed, 1 Nov 2023 at 13:58, Paul D. Smith wrote: > GNU Make is used by so many people for so many things, and I'm leery of > creating some new facility that ends up being "not really right" for what > people want to do, but that then must be maintained forever going forward. > It seems to me to

Re: [bug #64571] Add option to print targets

On Tue, 2023-10-31 at 17:14 -0400, Benjamin Tilley wrote: > Follow-up Comment #1, bug #64571 (project make): > > I'm also interested in this feature. I often find when coming back to > an old > project I want a quick way to list the possible targets so that I > remember > what `make` invocation I

Re: [bug #64472] $(CP) is an empty string

On Wed, 26 Jul 2023 01:37:11 -0400 (EDT) > ... I see that rm, which was on the list of directly invokable utilities > with cp, nonetheless has an RM namesake, which contains the very much > conventional, but non-obvious and misleading, -f. AR is there alright but, > had the OP chosen INSTALL as th

Re: [bug #64288] The flag --no-print-directory becomes effective too early

On Wed, 2023-06-14 at 09:52 -0400, Dmitry Goncharov wrote: > Prior versions of make ignored the "MAKEFLAGS += --no-print- > directory" setting. Just to be very clear, it was ignored for _this_ instance of make, but was in effect for any _sub-make_ that was invoked. > if i understood you correctly

Re: [bug #64288] The flag --no-print-directory becomes effective too early

On Fri, Jun 9, 2023 at 10:47 AM Masahiro Yamada wrote: > Previously, I was able to do > "MAKEFLAGS += --no-print-directory" in a single place, > but it is now impossible. Prior versions of make ignored the "MAKEFLAGS += --no-print-directory" setting. You can see that even the "Leaving directory.

Re: [bug #64288] The flag --no-print-directory becomes effective too early

Just to note you can still post comments to bugs in Savannah, and they will be sent out to the list like any other bug, even if they're closed. But discussing on the mailing list directly is fine too! On Fri, 2023-06-09 at 23:46 +0900, Masahiro Yamada wrote: > On Fri, Jun 9, 2023 at 9:39 PM Paul

Re: [bug #64288] The flag --no-print-directory becomes effective too early

On Fri, Jun 9, 2023 at 9:39 PM Paul D. Smith wrote: > > Update of bug #64288 (project make): > > Status:None => Not A Bug > Open/Closed:Open => Closed > > ___ > > Follow-u

Re: bug

On Tue, 2023-02-14 at 23:22 +0100, Viktor Cada wrote: > I am new to Debian and when installing apache2 i got these error > codes: > > collect2: error: ld returned 1 exit status I suppose when you say "installing" apache2 you really mean "building" apache2. This error means the link command that

Re: [bug #61763] [PATCH] glob: Do not use realloc wrapper on FreeBSD

On Mon, 2023-01-02 at 10:47 -0500, Dmitry Goncharov wrote: > On Mon, Jan 2, 2023 at 9:50 AM Paul D. Smith > wrote: > > I decided to own this glob implementation > > Paul, do you mean that you decided to maintain glob impl in make? > If yes, do you still want to link against glibc impl, when avail

Re: [bug #61763] [PATCH] glob: Do not use realloc wrapper on FreeBSD

On Mon, Jan 2, 2023 at 9:50 AM Paul D. Smith wrote: > I decided to own this glob implementation Paul, do you mean that you decided to maintain glob impl in make? If yes, do you still want to link against glibc impl, when available? regards, Dmitry

Re: [bug #63516] `include` of absolute path prepends path with `./`

On Thu, Dec 15, 2022 at 4:17 PM anonymous wrote: > > Follow-up Comment #4, bug #63516 (project make): > > I've attached my fix in case it's helpful. Also attached is a small fix to > `bootstrap.bat` that I had to make to get it to build with `tcc`. > > (file #54105, file #54106) Regarding this f

Re: [bug #63307] make 4.4 passes ignored SIGPIPE on to children

On 11/9/22 21:36, Paul D. Smith wrote: Follow-up Comment #18, bug #63307 (project make): I can see an argument for both sides ("give up immediately" and "run to completion"). Most likely it's one of those things where different people legitimately want different behaviors. But I think that sin

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

On Tue, Nov 8, 2022 at 10:40 AM Dmitry Goncharov wrote: > > Follow-up Comment #9, bug #63330 (project make): > > Depending on _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS dirent has d_ino and > d_off fields 32 or 64 bits wide. > Looks like in your case the remote machine has 64bit d_ino and d_off and

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:

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

Re: [bug #63307] make 4.4 passes ignored SIGPIPE on to children

On Sat, Nov 5, 2022 at 1:34 PM Dmitry Goncharov wrote: > Follow-up Comment #6, bug #63307 (project make): > > > If SIGIGN was ignored before make was started though, it should remain > ignored, even for make's children, see also >

Re: [bug #63315] Test failures with 4.4 on OpenBSD

On Fri, Nov 4, 2022 at 3:51 PM Brad Smith wrote: > I can give you access to a system to test with. Brad, if you created an account for me, i'd be able to take care of this. Thank you regards, Dmitry

Re: [bug #63248] Ignore sigpipe.

On Nov 02 2022, Paul D. Smith wrote: > Make should not pass the ignore to children; if it does that's a bug in make > and should be reported. I don't see anything that unignores SIGPIPE. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3

Re: [bug #62936] Confusing description of chained rules in the manual

On Sat, 2022-10-22 at 21:13 +0100, Tim Murphy wrote: > On Sat, 22 Oct 2022, 20:33 Paul Smith, wrote: > > "Updating a target" has a well-defined meaning that's used > > everywhere in the documentation and the mailing lists etc., and > > it's also the term used everywhere in the POSIX spec for the >

Re: [bug #62936] Confusing description of chained rules in the manual

On Sat, 22 Oct 2022, 20:33 Paul Smith, wrote: > On Wed, 2022-10-19 at 07:28 +0100, Tim Murphy wrote: > > Outside of make "update" implies existence - we use CRUD as a term > > for example not RUD. Why redefine the language? Actually for > > databases the word "upsert" has been invented to explai

Re: [bug #62936] Confusing description of chained rules in the manual

On Wed, 2022-10-19 at 07:28 +0100, Tim Murphy wrote: > Outside of make "update" implies existence - we use CRUD as a term > for example not RUD.  Why redefine the language? Actually for > databases the word "upsert" has been invented to explain a roughly > analagous situation is going on - perhaps

Re: [bug #63157] Unlink temporary files.

Paul D. Smith wrote: > Follow-up Comment #21, bug #63157 (project make): > > The only places leftover files may happen is (a) on Windows, only when (b) you > kill GNU make with ^C or similar. > > Any other leftover files should not happen. Please provide details of the > names of the files that

Re: [bug #62936] Confusing description of chained rules in the manual

On Sat, 15 Oct 2022 at 23:57, Paul D. Smith wrote: > Follow-up Comment #1, bug #62936 (project make): > > I don't know why you say "you cannot update a non-existing file": make does > this all the time! When you start make in a clean directory there are no > object files, for example, and so tho

Re: [bug #63070] posix_spawn fails to run a child process.

Alejandro Colomar (21 September 2022 11:46) >> If the function is returning 0, there's no error, and errno shouldn't be read > I guess you maybe didn't state it here as obvious, but to me it's not by > reading the conversation: Apart from posix_spawn(3) returning 0 and setting > errno to ENOEXEC,

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

Re: Bug Report

On Sat, 2022-09-10 at 23:12 +0300, Fosil Crypto wrote: > ubuntu@ip-172-31-95-154:~$ make ncdu gcc git jq chrony liblz4-tool -y > make: invalid option -- 'y' This is not a bug. You are just invoking make incorrectly.

Re: [bug #63016]

> Compiling the Linux kernel with git make HEAD: > > *** Recursive variable 'KERNELRELEASE' references itself (eventually).  Stop. Huh, I saw that too when compiling kernel modules under the control of the same proprietary make files as provoked my original report. I was really not looking for

Re: [bug #62936] Confusing description of chained rules in the manual

Hi Konrad, > Trying to understand a bug in my Makefile, I consulted the manual > section on chained rules > (https://www.gnu.org/software/make/manual/html_node/Chained-Rules.html#Chained-Rules) > and found the following paragraph, which is more confusing than > helpful: >> The first difference is

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 This is not the error messag

Re: [bug #62840] make --version in pipe return SIGPIPE

On Sat, 30 Jul 2022 13:26:46 -0400 (EDT) Martin Dorey wrote: > Follow-up Comment #2, bug #62840 (project make): > > Just for completeness or academic interest, then, this makes it happen > reliably for me: > > > set -o pipefail; { ruby -we '$stdout.write("x" * 4096)'; make --version; } | > head

Re: [bug #60165] Multiple pattern rules with single rule

On Tue, 2022-07-19 at 21:00 +0200, Jean-Baptiste Poittevin wrote: > Well, allow me to cite the documentation linked : > > This is a behaviour which seems reasonable to me, sufficiently > consistent for me to try to implement it. It is somehow sad that the > same rule is not applicable for pattern

Re: [bug #60165] Multiple pattern rules with single rule

Le 2022-07-19 14:52:40, Paul Smith a écrit : > On Tue, 2022-07-19 at 20:26 +0200, Jean-Baptiste Poittevin wrote: > > a% b%: % > >     cp $< $@ > > This rule is not well-formed. By declaring two patterns as targets, > you are telling make that your recipe will build both targets after > succes

Re: [bug #60165] Multiple pattern rules with single rule

On Tue, 2022-07-19 at 20:26 +0200, Jean-Baptiste Poittevin wrote: > a% b%: % >     cp $< $@ This rule is not well-formed. By declaring two patterns as targets, you are telling make that your recipe will build both targets after successfully being invoked one time. If your recipe doesn't actu

Re: [bug #60165] Multiple pattern rules with single rule

M. Smith, Le 2022-07-19 14:00:59, Paul D. Smith a écrit : > Follow-up Comment #1, bug #60165 (project make): > > The attached patch (if I understand it correctly) will break the large > majority of makefiles that use pattern rules today, including even some > built-in rules in GNU make. It's cle

Re: [BUG] inconsistency in $localstatedir and $runstatedir

Hi Alfred, On 7/18/22 13:51, Alfred M. Szmidt wrote: So you're saying that "should normally be" doesn't mean the "the default value should normally be", but rather that "commonly, people use". Right, the _default_ value depends on _your_ system. On some systems, it is one thing, an

Re: [BUG] inconsistency in $localstatedir and $runstatedir

So you're saying that "should normally be" doesn't mean the "the default value should normally be", but rather that "commonly, people use". Right, the _default_ value depends on _your_ system. On some systems, it is one thing, and on other it is something else. Which is why "you" (you i

Re: [BUG] inconsistency in $localstatedir and $runstatedir

Hi Alejandro, I think the source of the confusion is that "Should normally be" and how you should write a default value don't match up because it is normal to use non-default values. So systems are commonly set up with localstatedir=/usr/var and runstatedir=/var/run, despite t

Re: [BUG] inconsistency in $localstatedir and $runstatedir

Hi Edward, On 7/18/22 12:25, Edward Welbourne wrote: Hi Alejandro, I think the source of the confusion is that "Should normally be" and how you should write a default value don't match up because it is normal to use non-default values. So systems are commonly set up with localstatedir=/usr/var

Re: [BUG] inconsistency in $localstatedir and $runstatedir

Hi Alejandro, I think the source of the confusion is that "Should normally be" and how you should write a default value don't match up because it is normal to use non-default values. So systems are commonly set up with localstatedir=/usr/var and runstatedir=/var/run, despite the fact that their d

Re: [BUG] inconsistency in $localstatedir and $runstatedir

On 7/18/22 11:17, Alfred M. Szmidt wrote: Oh, there _is_ a bug. Compare what the documentation says, with a bit of variable expansion that I did to show the bug (between parentheses): Documentation says: $prefix Should normally be */usr/local* $localstate

Re: [BUG] inconsistency in $localstatedir and $runstatedir

Oh, there _is_ a bug. Compare what the documentation says, with a bit of variable expansion that I did to show the bug (between parentheses): Documentation says: $prefix Should normally be */usr/local* $localstatedir Should normally be */usr/local/var*

Re: [BUG] inconsistency in $localstatedir and $runstatedir

Hi Alfred, On 7/17/22 16:18, Alfred M. Szmidt wrote: How can $localstatedir be $prefix/var and at the same time $runstatedir be /var/run (notice no prefix) if it is defined as $localstatedir/run. Because prefix is normally /usr, and it was/is common to use /usr/var for exactly that purp

Re: [BUG] inconsistency in $localstatedir and $runstatedir

How can $localstatedir be $prefix/var and at the same time $runstatedir be /var/run (notice no prefix) if it is defined as $localstatedir/run. Because prefix is normally /usr, and it was/is common to use /usr/var for exactly that purpose. Where as runstatedir was in /var/run and not /usr.

Re: [BUG] inconsistency in $localstatedir and $runstatedir

Hi Paul, On 7/14/22 18:11, Paul Smith wrote: On Thu, 2022-07-14 at 14:16 +0200, Alejandro Colomar wrote: How can $localstatedir be $prefix/var and at the same time $runstatedir be /var/run (notice no prefix) if it is defined as $localstatedir/run. This I don't know about: it might be a proble

Re: [BUG] inconsistency in $localstatedir and $runstatedir

On Thu, 2022-07-14 at 14:16 +0200, Alejandro Colomar wrote: > How can $localstatedir be $prefix/var and at the same time > $runstatedir be /var/run (notice no prefix) if it is defined as > $localstatedir/run. This I don't know about: it might be a problem in the description. > Since the FHS doesn

Re: [bug #62706] Restrict second expansion to targets which are being built.

On Tue, Jul 5, 2022 at 12:34 PM Edward Welbourne wrote: > was thinking of the fact that, if you'd started with > > all: $$(info 2nd expansion for all) hello.tsk bye.tsk; echo built both > > then its info would appear first, although its rule would be run last. That's correct. $$(info 2nd expansio

Re: [bug #62706] Restrict second expansion to targets which are being built.

On Tue, Jul 5, 2022 at 5:19 AM Edward Welbourne wrote: >> I would have expected the order to be the exact reverse of the >> order of building: Dmitry Goncharov (5 July 2022 14:29) replied: > i guess, an example will make it more clear. > > $ cat makefile > .SECONDEXPANSION: > all: hello.tsk bye.

Re: [bug #62706] Restrict second expansion to targets which are being built.

On Tue, Jul 5, 2022 at 5:19 AM Edward Welbourne wrote: > I would have expected the order to be the exact reverse of the > order of building: i guess, an example will make it more clear. $ cat makefile .SECONDEXPANSION: all: hello.tsk bye.tsk hello.tsk: $$(info 2nd expansion of prereqs of $$@);

Re: [bug #62706] Restrict second expansion to targets which are being built.

Dmitry Goncharov (5 July 2022 01:42) wrote (inter alia): > 2. Causes all prerequisites to be second expanded in the same order > they are being built. Really ? I would have expected the order to be the exact reverse of the order of building: src = main.c hdr = lib.h prog: $$(src); $(CC) -o $@ $<

RE: [bug #62654] Add z/OS support

On July 3, 2022 7:33 PM, Paul Smith wrote: >I prefer to do the review via email rather than in the Savannah bug tracker >which >has pretty annoying markup. > >I would appreciate a somewhat comprehensive commit message or ChangeLog for >this set of patches, at least explaining some of the less obvi

RE: [bug #62654] Add z/OS support

I prefer to do the review via email rather than in the Savannah bug tracker which has pretty annoying markup. I would appreciate a somewhat comprehensive commit message or ChangeLog for this set of patches, at least explaining some of the less obvious modifications. > +set -x > +if [ ! ${PLATFORM

Re: bug or feature make -j4 option? but successfully applied all changes!

> bug or feature make -j4 option? but successfully applied all changes! This: /var/lib/dkms/rtl8821ce/5.5.2.1/build/os_dep/osdep_service.c: In function ‘thread_exit’: /var/lib/dkms/rtl8821ce/5.5.2.1/build/os_dep/osdep_service.c:1297:2: error: implicit declaration of function ‘complete_and_exit’

Re: [bug #62441] Recursive make & PHONY = targets being rebuilt [feature reques]

> I have two makefiles: > > *Makefile* > > .PHONY: other_file > other_file: > $(MAKE) -f Makefile2 other_file > > my_file: other_file > touch $@ > > > *Makefile2* > > other_file: > touch $@ > > > > When I first run the command, it builds my_file and other_file as expected

Re: [bug #62173] Fix test features/archives.

On Sun, Apr 24, 2022 at 2:48 PM Jeffrey Walton wrote: > Be sure to test the change on OpenBSD. In the past OpenBSD needed the > dash for options. I'm not sure if it is needed nowadays. The change that was mentioned added the dash. The current default ARFLAGS=-rv, which is also required by posix.

Re: [bug #62173] Fix test features/archives.

On Sun, Mar 13, 2022 at 10:49 AM Dmitry Goncharov wrote: > > Follow-up Comment #2, bug #62173 (project make): > > The patch contains the following changes > > -my $arflags = 'rv'; > +my $arflags = '-rv'; > +if ($^O eq 'aix') { > +$arflags = "-Xany -rv"; > +} > > > That reason for the

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

Eddy, thanks again. yes, one should re-read manuals. and, remember what one reads! > I confess I don't see how a sub-make would really help there. I > generally do my git changes separately from invoking make - and, even > then, incremental builds sometimes require (at least) a purge of > gene

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

Re: Bug report made anonymously should be assigned to my username on Savannah for receiving updates on it

On Fri, 2022-03-18 at 21:12 +, Lahfa Samy wrote: > I've reported this bug anonymously : > https://savannah.gnu.org/bugs/index.php?62200 and would like to > receive updates/comments on it by mail on my Savannah account, I > don't know if the bug report could be assigned to me or the "posted > b

Re: [bug #62118] Fix parsing of command line options -f, --file, --makefile.

On Sun, Feb 27, 2022 at 6:11 PM Paul D. Smith wrote: > > Update of bug #62118 (project make): ... > When looking at the test results I noticed that we were leaving the temporary > files behind if we had to re-exec, because the re-exec'd version of make > didn't realize they were temporary. > > I d

Re: Bug in $(shell ...) I can't understand

On Sun, 2022-02-06 at 17:12 -0500, Dmitry Goncharov wrote: > This behavior is correct, is not it? > > $ cat makefile > SHELL:=/badpath/bash > value:=$(shell echo hello world) > all: ; $(info $(value)) > $ make >/dev/null > make: /badpath/bash: No such file or directory > $ > > stdout is redirecte

Re: Bug in $(shell ...) I can't understand

On Sun, Feb 6, 2022 at 3:28 PM Paul Smith wrote: > Oh. I see the problem. If the shell exits with an exit code of 127 > then make's shell function assumes that it failed because the sub- > process was not found, and it actually writes its output to stderr!! This behavior is correct, is not it?

Re: Bug in $(shell ...) I can't understand

On Sun, 2022-02-06 at 15:21 -0500, Paul Smith wrote: > I'm not sure this is correct.  I will need to think about it. I decided this was a bug and changed the behavior for the next release.

Re: Bug in $(shell ...) I can't understand

On Sun, Feb 06, 2022 at 03:21:39PM -0500, Paul Smith wrote: > On Sun, 2022-02-06 at 20:18 +0300, Dmitry V. Levin wrote: > > 4175643 write(2, "/bin/sh: bad-program: command no"..., > > 40) = 40 > > 4175640 <... read resumed>"/bin/sh: bad-program: command no"..., 200) = 40 > > 4175640 read(5,  > >

Re: Bug in $(shell ...) I can't understand

On Sun, Feb 6, 2022 at 8:19 AM Dmitry V. Levin wrote: > > On Sun, Feb 06, 2022 at 11:23:03AM -0500, Paul Smith wrote: > > OK, someone posted a question to SO and that led me to an hour or more > > of banging my head against a wall trying to understand what's > > happening... and I can't. > > > > T

Re: Bug in $(shell ...) I can't understand

On Sun, 2022-02-06 at 20:18 +0300, Dmitry V. Levin wrote: > 4175643 write(2, "/bin/sh: bad-program: command no"..., > 40) = 40 > 4175640 <... read resumed>"/bin/sh: bad-program: command no"..., 200) = 40 > 4175640 read(5,  > 4175643 +++ exited with 127 +++ > 4175640 <... read resumed>"", 160)

Re: Bug in $(shell ...) I can't understand

n behalf of Dmitry V. Levin Sent: Sunday, February 6, 2022 09:18 To: Paul Smith Cc: bug-make@gnu.org Subject: Re: Bug in $(shell ...) I can't understand * EXTERNAL EMAIL * On Sun, Feb 06, 2022 at 11:23:03AM -0500, Paul Smith wrote: > OK, someone posted a question to SO and that

Re: Bug in $(shell ...) I can't understand

On Sun, Feb 06, 2022 at 11:23:03AM -0500, Paul Smith wrote: > OK, someone posted a question to SO and that led me to an hour or more > of banging my head against a wall trying to understand what's > happening... and I can't. > > The problem is that the user would like to invoke $(shell ...) and >

  1   2   3   4   5   6   7   8   9   10   >