Re: [doc] MAKEOVERRIDES is undocumented

On Mon, 2022-12-19 at 16:45 +0100, Alejandro Colomar wrote: > I had to search some related things in stackoverflow to find this.  I > think you should document this (and a few others) in 'Other Special > Variables' > . I

Re: Old timestamps in the future?

On Fri, 2022-12-09 at 15:06 +, Edward Welbourne wrote: > MS's time_t is indeed 64-bit; and MS's time_t-related POSIX functions > don't support times before the start of 1970, i.e. negative time_t > values, so it is eminently plausible MS's time_t is a 64-bit unsigned > int.  (Those same

Re: Old timestamps in the future?

On Fri, 2022-12-09 at 14:59 +0100, Gisle Vanem wrote: > A file dated '1. Jan. 1970, 00:20' is wrongly claimed to be in the > future. Some wrap going on here or something wrong with the logic in > 'remake.c'? But a file dated '1. Jan. 1970, 01:00' is > accepted fine. > > Looking at

Re: bootstrap fails due to certification expiration

On Fri, 2022-11-18 at 20:34 +0900, KO Myung-Hun wrote: > Downloaded: 10 files, 546K in 1.9s (283 KB/s) > ./bootstrap: autopull.sh failed. > - > > Any idea? I'm not sure why it fails but looking at the script it seems you can run: ./autopull.sh --skip-po to skip the downloading of the PO

Re: bootstrap fails due to certification expiration

On Mon, 2022-11-14 at 13:29 +0900, KO Myung-Hun wrote: > ./autopull.sh: getting translations into po/.reference for make... > ERROR: cannot verify translationproject.org's certificate, issued by > 'CN=R3,O=Let\'s Encrypt,C=US': >   Issued certificate has expired. > To connect to

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 implementation for OS/2? I'm

Re: GNU make for x86_64-pc-linux-gnu

On Wed, 2022-11-09 at 14:58 +, Dadzio, Joerg wrote:  > I want to inspect the preprocessor output of  ‘make’ for .c projects > in order to make sure my set of ‘#define …’ instructions does work > fine. Note, there is no such thing as "preprocessor output of make". Makefiles are not C/C++

Re: 4.4: embeds volatile information in MAKEFLAGS

On Mon, 2022-11-07 at 14:59 -0500, Paul Smith wrote: > I agree that we should drop down to "jobserver unavailable" here > rather than having a fatal error. I have a change that implements this now.

Re: 4.4: embeds volatile information in MAKEFLAGS

On Mon, 2022-11-07 at 21:55 +0100, Steffen Nurpmeso wrote: >  |However, I don't think that any changes being made for GNU Make 4.4 >  |compatibility, would render the makefile unusable with GNU Make 4.3 >  |(unless they start actually using the new features like the new >  |functions, but I don't

Re: 4.4: embeds volatile information in MAKEFLAGS

On Mon, 2022-11-07 at 21:24 +0100, Steffen Nurpmeso wrote: > What would interest me now.  Will there be GNU make 4.4.1? > (On the left and right i see quite some changes of projects to > become compatible with GNU make 4.4 though, CRUX Linux imported > a pretty lengthy glibc patch, and on the

Re: 4.4: embeds volatile information in MAKEFLAGS

On Mon, 2022-11-07 at 20:32 +0100, Steffen Nurpmeso wrote: > mkdir /tmp/t > cd /tmp/t > cat > makefile <<'EOT' > .NOTPARALLEL: > .WAIT: # Luckily BSD make supports specifying this as target, too > config: > @{ echo MAKE=\"$(MAKE)\";echo MAKEFLAGS=\"$(MAKEFLAGS)\"; } > > ./au;echo config >

Re: GNU Make 4.4 released!

On Mon, 2022-11-07 at 20:40 +0900, KO Myung-Hun wrote: > May I take over OS/2 port maintenance ? > For this, what should I do ? 1. Subscribe to this mailing list and announce your intention to work on this (to prevent possible duplication of effort). 2. Download the latest release

Re: please keep up supporting AmigaOS

On Thu, 2022-11-03 at 09:53 -0900, Philip Guenther wrote: > Well, the good news is that you have lots of volunteers to test new > versions where you refactor the code to reduce the intrusiveness of > the Amiga changes! > > "Hi, you expressed interest in GNU make continuing to support your > OS;

Re: please keep up supporting AmigaOS

On Thu, 2022-11-03 at 19:06 +0100, Henrik Carlqvist wrote: > Thank you for joining the group of Amiga users that now are spamming > all the subscribers of the GNU mailing list. It's unfortunate that I asked for responses to the bug-make list instead of to my private account: I sort of assumed

Re: Please don't drop support for AmigaOS

On Thu, 2022-11-03 at 10:36 +0100, John Paul Adrian Glaubitz wrote: > I just read the release announcement for GNU Make 4.4 that deprecated > support for AmigaOS. > > Since AmigaOS is still being actively developed and deployed, I would > like to ask for AmigaOS support to remain part of GNU

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

On Thu, 2022-11-03 at 06:57 +0100, Christian Jullien wrote: > Here is the correct one for make v4.4 on Solaris 10 with gcc 9.5.0: > > > gcc -DHAVE_CONFIG_H -I. -I../src   -I/usr/local/include  -Wno-cast- > qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef - > Wno-unused-function

Re: [PATCH] Bad timestamps on MinGW32

On Wed, 2022-11-02 at 16:22 -0400, Jeffrey Walton wrote: > A first class configure test that checks for the size of time_t will > probably be your best choice. Unfortunately we don't (always) run configure on Windows (it's possible to build GNU make on Windows systems where you can't run

Re: FreeBSD 13.1-RELEASE make version

On Tue, 2022-11-01 at 18:39 -0300, Kaíque Kandy Koga wrote: > Version is not being displayed on FreeBSD. > > > [kandy@ ~/a]$ make --version I suspect you are using BSD make, not GNU make. Please verify which make you are using.

Re: FreeBSD 13.1-RELEASE $< and $^

On Tue, 2022-11-01 at 18:37 -0300, Kaíque Kandy Koga wrote: > $< and $^ do not seem to work on FreeBSD. I suspect you are using BSD make, not GNU make. Please verify which make you are using.

Re: duplicate dependencies (with .WAIT)

On Tue, 2022-11-01 at 22:51 +0100, Frank Heckenbach wrote: > That's why I only suggested a warning since it may be un expected > (especially with ".WAIT") or unintended (even in your example at the > end, why would one put "pause" twice intentionally). I see. We can't do this; there are tons of

Re: duplicate dependencies (with .WAIT)

On Tue, 2022-11-01 at 14:15 +0100, Frank Heckenbach wrote: > So "pause" is run only once. Now, I suppose that's as it's supposed > to be (by comparison with the same rule without ".WAIT"), and I > don't expect you to change anything about it, so that's basically > just for information to anyone

Re: Doubts about .WAIT and .NOTPARALLEL (was: GNU Make 4.4 released!)

On Mon, 2022-10-31 at 11:06 +0100, Alejandro Colomar wrote: > On 10/31/22 08:01, Paul Smith wrote: > > * New feature: The .WAIT special target > > I'm curious: what is .WAIT made for? As mentioned in the NEWS, it's _primarly_ there because the next release of the POSIX spec will

GNU Make 4.4 released!

r (1): * doc/make.texi (Automatic Variables): Relocate the $? example Noah Goldstein (2): hash: Remove unnecessary isupper() check before tolower() Replace strcmp() with memcmp() where possible Paul Eggert (2): Remove arbitrary limits on intcmp integers Support systems

Re: Question: make x86_64_defconfig

On Fri, 2022-10-28 at 13:10 +, Durig, Burak W wrote: > I have an A 12 based emulator I want to run, I’m following a guide > and I’m stuck at creating the below:  > $ x86_64_ranchu_defconfig  > The error I keep seeing is that the default configuration can’t be > found. I can type

Re: GNU make 4.3.92 on mingw

On Tue, 2022-10-25 at 22:13 +0300, Eli Zaretskii wrote: > > So if we see a difference it must be that there's some OTHER > > difference not just CRLF.  Or, the test suite comparison has a > > bug.  I'll have to look more closely at the output. > > I do see differences unrelated to CRLF, see

Re: GNU make 4.3.92 on mingw

On Tue, 2022-10-25 at 19:37 +0300, Eli Zaretskii wrote: > > A lot of these seem to be CRLF errors in the diff, where it would > > otherwise match.  I know that the test framework does some > > manipulation of CRLF. > > If the test suite runs Diff, it should invoke it with the >

Re: GNU make 4.3.92 on mingw

On Tue, 2022-10-25 at 16:29 +0200, Bruno Haible wrote: > With GNU make 4.3.92, this is down to 75 test failures. Just curious how this MinGW test works; are you running the MinGW "cross-compiler" installed by the Cygwin package manager, and doing the build/test from within a Cygwin shell? A lot

Re: GNU Make 4.3.92 on OpenBSD 6.5

On Tue, 2022-10-25 at 16:32 +0200, Bruno Haible wrote: > On OpenBSD 6.5, I see 6 test failures. There are SIGSEGV in the loadapi tests; I'm not sure where to go with this as I'll need some debugging done on the segv at least a backtrace or something. And, there are timeout errors. If you change

Re: GNU make 4.3.92 on Cygwin

On Tue, 2022-10-25 at 16:27 +0200, Bruno Haible wrote: > With GNU make 4.3.92, we're down to 10 test failures. Just to note, I was able to install Cygwin64 on one of my Windows systems and the latest code built and ran with no failures there. All the failures on Cygwin in your tests are of this

Re: GNU make 4.3.92 on Manjaro 17 — bi-arch problem

On Tue, 2022-10-25 at 16:20 +0200, Bruno Haible wrote: > Unfortunately, it did not fix the problem. Find attached the details > of that failed build. Hm. The link test I added did fail, as expected, but somehow that did not translate to disabling Guile support. I must have messed up something

Re: GNU Make 4.3.92 release candidate available

On Tue, 2022-10-25 at 08:42 +0200, Martin Reinders wrote: > but from what Paul said in https://lists.gnu.org/archive/html/bug- > make/2019-05/msg00017.html > > > Argh, another glob.c issue.  I really need to figure out how to > > update to a newer version, preferably without breaking Windows AND

Re: GNU Make 4.3.92 release candidate available

On Mon, 2022-10-24 at 15:17 +0200, Frank Heckenbach wrote: > Paul Smith wrote: > > I expect this to be the final release candidate before GNU Make > > 4.4. I will probably allow for testing for about a week. > > All problems I reported appear fixed, thanks. Nice, thanks f

GNU Make 4.3.92 release candidate available

I expect this to be the final release candidate before GNU Make 4.4. I will probably allow for testing for about a week. GNU make is a tool which controls the generation of executables and other non-source files of a

Re: GNU make 4.3.91 on GNU/Hurd

On Wed, 2022-10-19 at 03:14 +0200, Bruno Haible wrote: > PATH_MAX does not exist on GNU/Hurd (intentionally, because file > names are of arbitrary length). Thanks, I've fixed this by setting a large value (4096) as PATH_MAX if it's not set anywhere. Ideally GNU make would also allow arbitrarily-

Re: GNU make 4.3.91 release candidate available

When replying to the release messages we should try to trim the "CC" list to avoid spamming the translators and testers. In future releases I will send separate announce emails to the lists, translators, and testers. On Wed, 2022-10-19 at 06:31 +0200, Frank Heckenbach wrote: > > * WARNING:

Re: GNU make 4.3.91 on Manjaro 17 — bi-arch problem

On Wed, 2022-10-19 at 02:20 +0200, Bruno Haible wrote: > The cause: > libguile-2.2.so happens to be installed only as 64-bit binaries, in > /usr/lib. > Not as 32-bit binaries, in /usr/lib32. Yet, /usr/include/guile/2.2/ > exists. I added extra configure checking to try to link with Guile, not

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 us

Re: GNU make 4.3.91 release candidate available

On Sat, 2022-10-22 at 10:16 -0400, Paul Smith wrote: > > This warning doesn't seem to be given for indirect targets as e.g. > > would be the case with bison and cc: %.y -> %.[ch] -> %.o which was > > the case that caused me problems with 4.3.90. I've since fixed my &g

Re: GNU make 4.3.91 on CentOS 8 Stream

On Sun, 2022-10-23 at 16:17 +0200, Bruno Haible wrote: > Paul Smith wrote: > > I bumped the timeout to 10 seconds because, why not?  I'll be > > interested to see if we still get these timeouts... > > Yes, with tmout changed from 4 to 10 in tests/thelp.pl, I still >

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: GNU make 4.3.91 on Debian 9.1

On Wed, 2022-10-19 at 15:59 +0200, Bruno Haible wrote: > > Maybe just augmenting the check target to do more? > > Yes. Instead of printing >   See .diff* files in work dir for details it could >   - generate a summary file with details (like test-suite.log, described >     above), and/or >   -

Re: GNU make 4.3.91 on CentOS 8 Stream

On Wed, 2022-10-19 at 04:44 +0200, Bruno Haible wrote: > > I saw a similar test timeout. > > If the test hit a timeout, the timeout is definitely too small. It's strange. The timeout on this is 4 seconds, but it's just waiting for a file to be created by a different target. It's hard to

Re: GNU make 4.3.91 on Cygwin

On Tue, 2022-10-18 at 23:37 -0400, Paul Smith wrote: > On Wed, 2022-10-19 at 03:01 +0200, Bruno Haible wrote: > > On Cygwin 2.9.0 (64-bit), compilation works fine, but there are 11 > > test failures. > > I don't test or support cygwin myself so it's not surprising.  The >

Re: GNU make 4.3.91 on Debian 9.1

On Wed, 2022-10-19 at 05:05 +, Martin Dorey wrote: > >  Is there any possibility of seeing the output > > Certainly, but I still don't want to spam the list to death with the > whole thing and I didn't spot anything interesting. I meant in general. For example, for the failures that appear

Re: GNU make 4.3.91 on Cygwin

On Wed, 2022-10-19 at 03:01 +0200, Bruno Haible wrote: > On Cygwin 2.9.0 (64-bit), compilation works fine, but there are 11 > test failures. I don't test or support cygwin myself so it's not surprising. The cygwin team apparently has a set of patches that they maintain for GNU make but I'm not

Re: GNU make 4.3.91 on Debian 9.1

On Wed, 2022-10-19 at 01:43 +0200, Bruno Haible wrote: > On Debian 9.1.0 / x86 (a machine with glibc 2.24), the compilation > succeeds but 3 tests fail. Is there any possibility of seeing the output generated during these runs, in addition to the work directory? The output generated often has

Re: "make check" failure on Solaris 10 as File::Temp->newdir is missing

On Tue, 2022-10-18 at 14:46 -0700, Paul Eggert wrote: > Solaris 10 (supported by Oracle through January 2024) uses Perl > 5.8.4. tests/README says Perl 5.004 or later is needed That is wrong. In fact the tests/README file hasn't been updated an a very long time (I actually forgot it was there).

GNU make 4.3.91 release candidate available

GNU make is a tool which controls the generation of executables and other non-source files of a program from the program's source files. You can learn more at: https://www.gnu.org/software/make/

Re: [PATCH] Fix bug in recipe line count overflow checking

On Sun, 2022-10-09 at 17:17 -0700, Paul Eggert wrote: > Without this patch, the shell command: > awk 'BEGIN { >    print "x:" >    for (i = 0; i < 65536; i++) > printf "\techo %d\n", i} >     ' | make -f - > incorrectly outputs only "make: 'x' is up to date." I applied a

Re: [PATCH] Fix some temp file issues

On Fri, 2022-10-07 at 21:37 -0700, Paul Eggert wrote: > On 10/7/22 05:36, Eli Zaretskii wrote: > > I'd appreciate a more high-level description of the idea of the > > change, in addition to the gory details. > > I gave it a shot in the attached patch, which is an improved version > of the

Re: [PATCH] shuffle: disable by default

On Sun, 2022-10-16 at 15:09 +0200, Yann E. MORIN wrote: > Sorry for causing confusion; I'll get my second coffee before I post > patches next time. No problem, thanks for checking!

Re: [PATCH] shuffle: disable by default

On Sun, 2022-10-16 at 12:17 +0200, Yann E. MORIN wrote: > Commit 621d3196fae9 ([SV 62100] Add '--shuffle' option support) > introduced randomisation of prerequisites, so as to detect more > build ordering issues, especially with parallel builds. It also > made randomisation the default. I'm not

Re: misinterpretation of shell $'...' escape form

On Sat, 2022-10-15 at 22:41 +0300, Poor Yorick wrote: > on an Ubuntu 22.04 system, GNU Make 4.3, Bash 5.1.16(1) GNU make, like all POSIX compliant makes, does not run bash. It runs the shell provided in the make variable (not the shell variable!) SHELL. That value is, by default, /bin/sh which

Re: Small DJGPP specific patch.

On Wed, 2022-10-12 at 23:33 +0200, Juan Manuel Guerrero wrote: > Sorry, I have noted that the patch has been malformed by the mail > program so I submit the same a second time.  Excuse the > inconveniences. It's small enough that I would just apply it by hand, but thanks for sending an update,

Re: Small DJGPP specific patch.

On Wed, 2022-10-12 at 22:18 +0200, Juan Manuel Guerrero wrote: > Here is a small patch to get the current make code compiled and > running on MSDOS/FreeDOS using DJGPP.  I assume that for such minor > changes no paper work is required. Correct. But, note that the FSF considers contributions

Apologies for delay...

I'd hoped to put out a second RC last week but I've had some work emergencies that have been wreaking havoc with my schedule since last Friday. Things appear to be more or less under control and so I expect to get it out this week, with some fixes from Dmitry and PaulE. FYI...

Re: shell function: confusing error when shebang incorrect

On Sun, 2022-10-09 at 13:08 -0400, Kirill Elagin wrote: > 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. > > I am not convinced that platform-specific handling is not practical, > given that

Re: [PATCH] Port to 32-bit long + 64-bit time_t

On Tue, 2022-10-04 at 09:06 +0300, Eli Zaretskii wrote: > > From: Paul Smith > > Cc: bug-make@gnu.org > > Date: Mon, 03 Oct 2022 16:14:01 -0400 > > > > I needed another set of changes, since intmax_t is a new type and > > is not available on Windows so we need

Re: [PATCH] Port to 32-bit long + 64-bit time_t

On Sun, 2022-10-02 at 17:06 -0700, Paul Eggert wrote: > On 10/2/22 14:09, Paul Smith wrote: > > > I applied these changes but made a few mods: > > Thanks. I assume you'll push this to savannah at some point? Pushed now. I needed another set of changes, since intm

Re: [PATCH] Port to 32-bit long + 64-bit time_t

On Sun, 2022-10-02 at 17:48 -0400, rsbec...@nexbridge.com wrote: > > I understand that this type of reuse makes things easier for the > > gnulib folks, but for GNU make I'm not ready to drop support for > > platforms that are not POSIX enough to run configure, and that > > don't already have

Re: [PATCH] Port to 32-bit long + 64-bit time_t

On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote: > (This would not be needed if 'make' used Gnulib's inttypes module.) I would be happy to use it, if using it didn't import a ton of other things that require POSIX tools AND an already-working make program. I understand that this type of

Re: [PATCH] Port to 32-bit long + 64-bit time_t

On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote: > On 9/21/22 23:49, Eli Zaretskii wrote: > > This will cause problems in the native MS-Windows builds, where > > printf in the system C runtime doesn't support %lld and %llu. > > Thanks for the review. Revised patch attached. It also addresses

Re: GNU make 4.3.90 release candidate available

On Sun, 2022-10-02 at 22:14 +0200, Frank Heckenbach wrote: > I have a pattern rule like "%.c %.h &: %.y" for a tool (Bison) that > may generate two output files (.c and .h), but in some cases > (depending on the option "--defines") only one of them (.c). The change was intentional, but has been

Re: Deprecating OS support

On Sat, 2022-10-01 at 15:26 -0400, rsbec...@nexbridge.com wrote: > > I'm not familiar with the project names so can you be clear about > > which port(s) are used by HPE NonStop?  Do both of these efforts > > refer to the VMS port? > > The NonStop ports would use __TANDEM not VMS. Hm. I don't

Re: Deprecating OS support

On Sat, 2022-10-01 at 14:02 -0400, rsbec...@nexbridge.com wrote: > The ITUGLIB project team maintains a port of GNU Make for currently > supported HPE NonStop Guardian platforms. We do intend to port 4.4 > when it is released. I am the official maintainer on the team, at > present. The HPE NonStop

Re: Deprecating OS support

On Sat, 2022-10-01 at 20:42 +0300, Eli Zaretskii wrote: > The DJGPP project has been routinely porting all versions of Make up > to and including 4.3. By "DJGPP project" I expect you are referring to the MSDOS port (I'm not familiar with all the alternative names). The thing that I'm

Deprecating OS support

Hi all; With the upcoming release (4.4) I intend to announce that I'll be removing support for the following platforms in the next, post-4.4 release: - OS/2 (EMX) - Amiga - Native MS-DOS For the first two, I suspect that whatever support we currently have is broken and it's not really

Re: GNU make 4.3.90 release candidate available

On Mon, 2022-09-26 at 21:46 +0300, Eli Zaretskii wrote: > > On Mon, 2022-09-26 at 20:23 +0300, Eli Zaretskii wrote: > > > The following tests should be disabled on MS-Windows, because > > > they cannot possibly work: > > > > I have access to a VM running Windows 10 with a relatively recent > >

Re: GNU make 4.3.90 release candidate available

On Mon, 2022-09-26 at 20:23 +0300, Eli Zaretskii wrote: > The following tests should be disabled on MS-Windows, because they > cannot possibly work: I have access to a VM running Windows 10 with a relatively recent Visual Studio install, with a recent Perl, and with the Git for Windows binaries

Re: GNU make 4.3.90 release candidate available

On Mon, 2022-09-26 at 12:16 -0400, David Boyce wrote: > BTW wget complains about the certificate: > > $ wget https://alpha.gnu.org/gnu/make/make-4.3.90.tar.gz > --2022-09-26 09:12:58--  https://alpha.gnu.org/gnu/make/make-4.3.90.tar.gz > Resolving alpha.gnu.org (alpha.gnu.org)... 209.51.188.21,

Re: Make 4.3.90 RC fails 3 tests on OpenBSD 7.1 i386

Thanks for testing. On Sun, 2022-09-25 at 17:25 -0700, Mike Gran wrote: > I configured it using configure with CC=clang and no other options. > > loadapi.mk.3 and loadapi.mk.7 both complain that testapi.so failed > to load.  If there is an actual testapi.so being built, I can't > find it. > >

Re: 4.3.90 release candidate segfaults on linux and solaris

On Sun, 2022-09-25 at 13:03 -0400, Paul Smith wrote: > The odd thing is that make ALREADY preserves the environment pointer > and restores it, but it does so after child_execute_job() is called > (after removing some ifdefs): Oh, well, clearly child_execute_job() is called from oth

Re: 4.3.90 release candidate segfaults on linux and solaris

On Sun, 2022-09-25 at 10:25 -0400, Dmitry Goncharov wrote: > However, the this does this reproduce on my sun. Sorry Dmitry but I didn't understand that sentence...? The odd thing is that make ALREADY preserves the environment pointer and restores it, but it does so after child_execute_job() is

Re: 4.3.90 release candidate segfaults on linux and solaris

On Sun, 2022-09-25 at 06:02 +, Martin Dorey wrote: > And vfork is where that happens.  If I’ve followed the thicket of > #ifdef correctly and understood the vfork man page, then this is > illegal when using vfork: > > https://github.com/mirror/make/blob/master/src/job.c#L2556 It's long past

Re: GNU make 4.3.90 release candidate available

On Sun, 2022-09-25 at 13:30 +0300, Eli Zaretskii wrote: > > From: Paul Smith > > Cc: bug-make@gnu.org > > Date: Sat, 24 Sep 2022 16:44:44 -0400 > > > > On Sat, 2022-09-24 at 16:41 -0400, Paul Smith wrote: > > > makeint.h already has HAVE_MAKEINT_H > >

Re: 4.3.90 release candidate segfaults on linux and solaris

On Sat, 2022-09-24 at 13:06 -0400, Paul Smith wrote: > > The crashes in solaris and linux are so similar, and go away also > > so similarly, that i would primarily think about size of types. > > Under cygwin and MacOS all sizes (pointers, long int, size_t, > > SIZE_MAX, ti

Re: GNU make 4.3.90 release candidate available

On Sat, 2022-09-24 at 16:41 -0400, Paul Smith wrote: > makeint.h already has HAVE_MAKEINT_H Doh, I meant HAVE_INTTYPES_H of course.

Re: GNU make 4.3.90 release candidate available

On Sat, 2022-09-24 at 21:09 +0300, Eli Zaretskii wrote: > MinGW does have inttypes.h, if you want to use PRId64 or somesuch, > and > if the other supported platforms have that. > > I'm fine with using our own definition for PRId64, if that's what you > prefer.  On makeint.h, I presume? makeint.h

Re: GNU make 4.3.90 release candidate available

On Wed, 2022-09-21 at 06:18 +0100, Sam James wrote: > Can I suggest forwarding to the platform-testers@ mailing list as > well? I've never heard of this; is it @gnu.org? Or somewhere else? A full email address would be useful and also if you have any information on this (a website or whatever)

Re: GNU make 4.3.90 release candidate available

On Sat, 2022-09-24 at 14:17 +0300, Eli Zaretskii wrote: > Here are the proposed patches: > > --- src/function.c~02022-09-18 22:06:17.0 +0300 > +++ src/function.c  2022-09-24 13:30:01.740875000 +0300 > @@ -823,6 +823,15 @@ func_wordlist (char *o, char **argv, con >    stop =

Re: GNU make 4.3.90 release candidate available

On Sat, 2022-09-24 at 14:09 +0300, Eli Zaretskii wrote: > I've built this with mingw.org's MinGW for native MS-Windows.  I > found several issues during the build, some of them specific to > Windows, others more general.  (I didn't yet run the test suite, I > intend to do that next.) > > Here are

Re: 4.3.90 release candidate segfaults on linux and solaris

On Sat, 2022-09-24 at 18:23 +0200, Denis Excoffier wrote: > The segfault also occurs without ‘env -i’. Thanks for helping me avoid that red herring. > The crashes in solaris and linux are so similar, and go away also so > similarly, that i would primarily think about size of types. Under >

Re: 4.3.90 release candidate segfaults on linux and solaris

On Sat, 2022-09-24 at 09:36 +0200, Denis Excoffier wrote: > In my specific configuration (under linux, with --disable-nls, > --disable-load, without using -j, using 'env -i make -d -n'), a > segfault always occurs around line 118 of src/expand.c: > > My linux is old (2.6.32), The kernel version

Re: 4.3.90 release candidate segfault on Mac OS 12.6

On Thu, 2022-09-22 at 20:34 +0100, John Graham-Cumming wrote: > Simply did ./configure. It’s an Intel Mac. Compiler seems to be > clang.  > > Doing a clean build shows a few warnings when compiling. Those are not a problem. In addition to answers to the questions I asked below, can you send the

Re: 4.3.90 release candidate segfault on Mac OS 12.6

On Thu, 2022-09-22 at 14:13 +0100, John Graham-Cumming wrote: > $ sw_vers > ProductName: macOS > ProductVersion: 12.6 > BuildVersion: 21G115 > >  $ ./make -v > GNU Make 4.3.90 > > $ cat Makefile > $(info $(wildcard foo)) > > $ rm -f foo > $ ./make > zsh: segmentation fault  ./make Hm, I cannot

Re: Make 4.3.90 breaks makefile of dtc

On Thu, 2022-09-22 at 10:54 +0200, Andreas Schwab wrote: > The issue is that the bison rule says it creates a %.output file, but > doesn't actually do that. > > %.tab.c %.tab.h %.output: %.y > @$(VECHO) BISON $@ > $(BISON) -b $(basename $(basename $@)) -d $< > > Note that no

GNU make 4.3.90 release candidate available

GNU make is a tool which controls the generation of executables and other non-source files of a program from the program's source files. You can learn more at: https://www.gnu.org/software/make/

Re: New release of GNU make

On Thu, 2022-09-15 at 14:00 +0100, Sam James wrote: > > Very preliminary results (only mild testing done so far) > > but the only failure I've hit thus far is autoconf-2.71: > > https://bugs.gentoo.org/869257. > > > > I'll continue testing. > > It's been very quiet indeed, which is good news.

Re: [SCM] make branch, master, updated. 4.3-234-gf6ea899d

On Tue, 2022-09-13 at 07:31 +0200, Frank Heckenbach wrote: > Is the last sentence grammatically correct? I'm not a native > speaker, but I'd have expected "a more unreliable way" or "a less > reliable way". This was rewritten a few times and meant to be "a less reliable" but I fat-fingered it.

Re: Cannot open jobserver ...

On Sun, 2022-09-11 at 12:52 -0400, Paul Smith wrote: > I'll look at little further. Oh I see. This is definitely a bug in the glibc build system, not in GNU make. I filed: https://sourceware.org/bugzilla/show_bug.cgi?id=29564

Re: Cannot open jobserver ...

On Sun, 2022-09-11 at 12:19 -0400, Paul Smith wrote: > On Sun, 2022-09-11 at 17:16 +0200, Toralf Förster wrote: > > make: invalid shuffle mode: '1662909020r' > > Hm.  Wonder where that "r" came from.  I will look. > > Oh I see it looks like an off-by-one buffer

Re: Cannot open jobserver ...

On Sun, 2022-09-11 at 17:16 +0200, Toralf Förster wrote: > make: invalid shuffle mode: '1662909020r' Hm. Wonder where that "r" came from. I will look. Oh I see it looks like an off-by-one buffer size error. Will fix, thanks.

Re: Cannot open jobserver ...

On Sun, 2022-09-11 at 11:02 +0200, Toralf Förster wrote: > make[1]: *** Cannot open jobserver > /var/tmp/portage/mail-client/s-nail-14.9.22/temp/GmQBwhVQ: No such > file or directory.  Stop. You also should be able to get back the old behavior by adding the --jobserver-style=pipe option to your

Re: Cannot open jobserver ...

On Sun, 2022-09-11 at 11:02 +0200, Toralf Förster wrote: > make[1]: *** Cannot open jobserver > /var/tmp/portage/mail-client/s-nail-14.9.22/temp/GmQBwhVQ: No such > file or directory.  Stop. It means someone or something deleted this file, while make was running. Maybe there's something in that

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: New release of GNU make

On Mon, 2022-09-05 at 03:47 +0100, Sam James wrote: > I started testing master recently and hit > https://savannah.gnu.org/bugs/?63016 > which prevented doing any more testing. Hopefully this is fixed. It works for the examples given anyway. I also downgraded the required version of autoconf to

Re: New release of GNU make

On Tue, 2022-09-06 at 18:59 +0100, Sam James wrote: > When we started testing in Gentoo (not unleashed onto users), > we had several failures that looks liked this almost immediately. I see, thanks. I will look at this tonight. Clearly this change introduces too severe a regression to accept

Re: New release of GNU make

On Mon, 2022-09-05 at 03:47 +0100, Sam James wrote: > I started testing master recently and hit > https://savannah.gnu.org/bugs/?63016 > which prevented doing any more testing. Just curious: why does this prevent doing any more testing? That issue needs to be carefully considered. In the

Re: Warnings when running "bootstrap"

On Mon, 2022-09-05 at 00:16 +, Bjarni Ingi Gislason via Bug reports and discussion for GNU make wrote: >   The compilation failed because I had an unclean git repository. > >   My compilation creates a lot of warnings, which could be reduced if > the header files were fixed > >     131

Re: Warnings when running "bootstrap"

On Sun, 2022-09-04 at 01:54 +, Bjarni Ingi Gislason via Bug reports and discussion for GNU make wrote: >   This causes failure when compiling. What is the failure? I don't get any failures. I do see the output here, but they are are just notes / warnings. Everything still works. If you

<    1   2   3   4   5   6   7   8   9   10   >