make 3.81: showing time differences

t;480 s" is understandable. Here's a patch to achieve this (note that there is no built-in printf directive that would limit the precision to 2 digits for values between 0 and 10, and drop fractional parts for values >= 100). 2007-10-27 Bruno Haible <[EMAIL PROTECTED]> *

make -q and phony targets

Hi, Paul Eggert discovered that phony targets cause "make -q" to fail. How to reproduce: Makefile all : sanity foo sanity : @test `expr 1 + 1` = 2 foo : echo > foo .PHONY: sanity =

Re: [Translation-team-de] Fehler in der Übersetzung von GNU make

Hello Paul, Florian Zeitz wrote to the German translation team on 2016-11-28: > Guten Tag zusammen, > > mir ist heute zu meiner großen Verwunderung ein `make --debug` Aufruf > gesegfaulted. Nach einigem Fehler suchen stellt sich heraus das dafür > folgende Übersetzung verantwortlich war: > > #:

make-3.79 on BeOS

d verified using "od -x" that it accurately represents the data layout of archive libraries on BeOS. 2000-04-17 Bruno Haible <[EMAIL PROTECTED]> * arscan.c [BeOS]: Add replacement for nonexistent . diff -r -c3 make-3.79.orig/arscan.c make-3.79/arscan.c *** make-3.79.orig/ars

Re: make-3.79 on BeOS

Paul D. Smith writes: > Does BeOS have enough of a shell that you can run configure and get > useful results? Yes. It uses GNU bash 2.03. > bh> 2) Error during "make distclean": > > bh> Apparently $(MAKE) = /bework/gnubuild/make-3.79/./make has been > bh> removed during the "make distcle

make compilation

Hi, Compiling make-3.79 with a current glibc snapshot. Autoconfiguration found out that the function 'strsignal' is available. But the header files declare it only when compiling with -D_GNU_SOURCE. (Which is ok, because 'strsignal' is by no means a standardized function.) So we get a warning:

make compilation, libit's gettext

Hi, Compiling make-3.79 with a current glibc snapshot. glibc-2.2 will have new features in gettext: automatic conversion of the translation to the right charset, and plural handling. 1) The default in all normal programs using AM_GNU_GETTEXT is to use the included gettext only if the system doe

Re: make compilation, libit's gettext

Paul D. Smith writes: > Bruno, do you have any thoughts on how we could _safely_ auto-detect a > "good" gettext implementation? I think it would be satisfactory to > detect a version of GNU gettext, and brand all other versions "bad", That's good enough, yes. You can detect GNU gettext by check

make-3.79.1 on glibc-2.1.91 (2)

if (FILE_TIMESTAMP_HI_RES) which macroexpands into if (0) Here is a patch to convert this 'if' test to a configure time test, thus avoiding the dependency on librt when the function clock_gettime is not really used. 2000-07-14 Bruno Haible <[EMAIL PROTECTED]> * configure.in

make-3.79.1 on glibc-2.1.91

Hi, make-3.79.1, built on a recent glibc snapshot, links with the shared library libutil, but doesn't any symbol from this library! Of course this costs startup time. The reason is the AC_FUNC_GETLOADAVG macro. It checks for getloadavg in -lutil. Now glibc-2.2 has getloadavg in libc, but it als

Re: make-3.79.1 on glibc-2.1.91 (2)

Paul D. Smith writes: > Seems like any decent compiler would omit this code! Since Linux is > using GCC, I would double-expect that. Maybe it only happens when you > build with optimization on? No compiler is required to omit "if (0)" code, and gcc indeed doesn't omit it if -O is not given. Th

Re: make-3.79.1 on glibc-2.1.91 (2)

Paul D. Smith writes: > it would be interesting to see if make included a reference to > libutil.so if compiled with -O. Yes, it did. I verified using "ldd ./make" that it had a reference to libutil.so before my patch, and that with my patch, the reference was gone. Bruno

undesirable .out rule

Hi, GNU make 3.79.1 apparently contains a pattern rule "%.out : % ; ..." which has some undesirable side effects. You can observe it as follows: - unpack ftp://alpha.gnu.org/gnu/gettext/gettext-0.11-pre1.tar.gz, - make a VPATH build: $ cd gettext-0.11-pre1 $ mkdir build $ cd build

incorrect error message

An incorrect and highly onfusing error message of GNU make 3.80, on Linux x86. To reproduce: In an otherwise empty directory, create this Makefile: %.erg : ../bar echo done %.erw : ../baz echo done foo.res : ../baz echo done =

"make -jN" requires mechanical changes to a Makefile

Hi, The GNU standards [1] say: "Try to make the build and installation targets, at least (and all their subtargets) work correctly with a parallel make." But supporting parallel requires, in some cases, mechanical changes to a Makefile. How about if GNU make was improved to not require me to

Re: "make -jN" requires mechanical changes to a Makefile

Hi Paul, > This makefile should be written correctly, as: > > all : copy1 copy2 copy3 copy4 > > copy1: Makefile > install -c -m 644 Makefile copy1 > copy2: Makefile > install -c -m 644 Makefile copy2 > copy3: Makefile > install -c -m 644 Makefile copy3 > c

Re: "make -jN" requires mechanical changes to a Makefile

Henrik Carlqvist wrote: > If you really prefer to write rules which generates more than one target > the "right" way to avoid parallel make would be to add the .NOTPARALLEL > target in the Makefile. This way allows to turn off parallel make for a single Makefile. Indeed, this might be a better com

Re: "make -jN" requires mechanical changes to a Makefile

Hi, I wrote: > The workaround is to introduce an intermediate target: > > === > all : copy1 copy2 copy3 copy4 > > copy1 copy2 copy3 copy4: install-copies > .PHONY: install-copies > install-copies: Makefile > install -c -m 644 Makefile copy1 >

Re: "make -jN" requires mechanical changes to a Makefile

Hi Paul, > > The real workaround goes like this: > > > > === > > all : copy1 copy2 copy3 copy4 > > > > copy1: Makefile > > install -c -m 644 Makefile copy1 > > install -c -m 644 Makefile copy2 > > install -c -m 644 Makefile

Re: "make -jN" requires mechanical changes to a Makefile

Henrik Carlqvist wrote: > Example with one rule creating 4 files: > > all : copy1 > > copy1: Makefile > install -c -m 644 Makefile copy1 > install -c -m 644 Makefile copy2 > install -c -m 644 Makefile copy3 > install -c -m 644 Makefile copy4 I think the "represen

Re: "make -jN" requires mechanical changes to a Makefile

Howard Chu wrote: > >> Example with one rule creating 4 files: > >> > >> all : copy1 > >> > >> copy1: Makefile > >> install -c -m 644 Makefile copy1 > >> install -c -m 644 Makefile copy2 > >> install -c -m 644 Makefile copy3 > >> install -c -m 644 Makefile copy4 > >

make-4.3: wildcard test #9 fails

Hi, Building GNU make 4.3 on Ubuntu 16.04, produces one failing test: $ ./configure --prefix=/arch/x86_64-linux-gnu/gnu-inst-make/4.3 $ make $ make check ... functions/wildcard .. FAILED (9/10 passed) ... vms/library

Re: make-4.3: wildcard test #9 fails

Hi Paul, > > Building GNU make 4.3 on Ubuntu 16.04, produces one failing test: > > This is because the glob() function in the older GNU libc has a bug > related to handling symlinks correctly. Gnulib provides a workaround against this bug in its 'glob' module [1]. But GNU make ships a copy of gl

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

Continuing this thread from May 2019 : The problem was: How can a rule that generates multiple files be formulated so that it works with parallel make? For example, a rule that invokes bison, or a rule that invokes a different

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

> === > all : copy1 copy2 copy3 copy4 > > copy1: Makefile > { test -f copy1 && test ! copy1 -ot Makefile; } || { rm -f copy4; > $(MAKE) copies; } > copy2: copy1 > { test -f copy2 && test ! copy2 -ot copy1; } || { rm -f copy4; $(MAKE) > copies;

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

Hi Paul, > There is a straightforward and portable way to do this even with > traditional make, it's just not as nice (but, nicer than changing all > the recipes to use test IMO! :)). > > If you have a rule like this: > > ... : > > > where generates all targets with one invocat

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

Henrik Carlqvist wrote: > 2) Don't mention some of the extra targets: > === > all : copy1 > > copy1: Makefile > install -c -m 644 Makefile copy1 > install -c -m 644 Makefile copy2 > install -c -m 644 Makefile copy3 > install -c -m 64

Re: Missing [/usr/local]/var/lib and [/usr/local]/tmp

Alejandro Colomar wrote: > I used the following: > > tmpdir := $(prefix)/tmp Writing it like this has two drawbacks: 1) The user cannot force a specific temporary directory by setting the TMPDIR environment variable. This may be blocking if the default temporary directory has not enou

Re: Missing [/usr/local]/var/lib and [/usr/local]/tmp

Jeffrey Walton wrote: > I believe MacOS maps /etc and /tmp to a private area for the user. > They are not world readable/writable. I believe Apple did it for > hardening. > > Here's from a MacOS X 10.5 machine I have: > > $ ls -l /etc /tmp > lrwxr-xr-x@ 1 root wheel 11 Feb 10 2015 /etc

GNU make 4.3.91 on Debian 9.1

On Debian 9.1.0 / x86 (a machine with glibc 2.24), the compilation succeeds but 3 tests fail. debian91-failures.tar.gz Description: application/compressed-tar

GNU make 4.3.91 on Debian 11.1

On Debian 11.1 / x86_64 (a glibc 2.31 system) compilation succeeds but there are 2 test failures. debian111-failures.tar.gz Description: application/compressed-tar

GNU make 4.3.91 on CentOS 8 Stream

On CentOS 8 Stream / x86_64 (a glibc 2.28 system), the compilation works fine, but the test suite has failures in the 'output-sync' category: - 3 failures in a build with gcc, - 4 failures in a build with clang-15.0.2. centos8s-gcc-failures.tar.gz Description: application/compressed-tar centos

GNU make 4.3.91 on Manjaro 17

On Manjaro Linux 17 (a glibc 2.28 system) in 64-bit mode, the compilation works fine, but there are 2 test failures. manjaro17-failures.tar.gz Description: application/compressed-tar

GNU make 4.3.91 on Manjaro 17 — bi-arch problem

On Manjaro Linux 17, installed from manjaro-kde-17.1.12-stable-x86_64.iso, it is possible to build 64-bit binaries (with CC="gcc") or 32-bit binaries (with CC="gcc -m32"). With CC="gcc -32", the compilation fails: $ make ... gcc -m32 -I/usr/include/guile/2.2 -pthread -g -O2 -Wl,--export-dynamic

GNU make 4.3.91 on openSUSE Leap 15.2

On OpenSUSE Leap 15.2 / x86_64 (a glibc 2.26 system), the compilation works fine but 3 tests fail. opensuse152-failures.tar.gz Description: application/compressed-tar

GNU make 4.3.91 on FreeBSD

On FreeBSD 11 / x86, the compilation works fine but 1 test fails. freebsd11-failures.tar.gz Description: application/compressed-tar

GNU make 4.3.91 on Solaris 11

On Solaris 11.4 / x86_64, in 64-bit mode, the compilation works fine, but there are 20 test failures. Likewise in 32-bit mode. On Solaris 11 OmniOS, in 64-bit mode, the compilation works fine, but there are 22 test failures. In 32-bit mode, even 26 test failures. On Solaris 11 OpenIndiana, in 64-

GNU make 4.3.91 on Cygwin

On Cygwin 2.9.0 (64-bit), compilation works fine, but there are 11 test failures. cygwin-failures.tar.gz Description: application/compressed-tar

GNU make 4.3.91 on mingw

On mingw (on Windows 10 in a Cygwin dev environment), compilation works fine, but there are 91 test failures. mingw-failures.tar.gz Description: application/compressed-tar

GNU make 4.3.91 on GNU/Hurd

On GNU/Hurd (from 2022), there is one compilation error: depbase=`echo src/arscan.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc-12 -DHAVE_CONFIG_H -Isrc -I../src -Ilib -I../lib -DLIBDIR=\"/home/bruno/lib\" -DLOCALEDIR=\"/home/bruno/share/locale\" -DINCLUDEDIR=\"/home/bruno/include\" -I/home/bru

GNU make 4.3.91 on other platforms

On some platforms, the compilation works fine and all tests pass: - Ubuntu / x86_64 22.04 - macOS 10.13 - NetBSD 9 Bruno

Re: GNU make 4.3.91 on CentOS 8 Stream

Dmitry Goncharov wrote: > > On CentOS 8 Stream / x86_64 (a glibc 2.28 system), the compilation works > > fine, > > but the test suite has failures in the 'output-sync' category: > > - 3 failures in a build with gcc, > > - 4 failures in a build with clang-15.0.2. > > > I saw a similar test timeou

Re: GNU make 4.3.91 on Debian 9.1

Hi Paul, > For example, for the failures that appear to be > timeouts sometimes the test suite will generate some information about > that, to stdout/stderr. > > Maybe there's some make target or script that, if it exists, the > platform testing scripts will run on failure to generate the tar fil

[bug #52018] suggestion: test case for glob with dangling symlink

Follow-up Comment #7, bug #52018 (project make): > So Debian Stretch aka 9, with glibc 2.24, fails, where Debian Buster aka 10, with glibc 2.28, passes, meaning that it exhibits the new behavior, where $(wildcard) matches even dangling symlinks. It would be possible for 'make' to not have this te

Re: GNU make 4.3.91 on Cygwin

Paul Smith wrote: > > > On Cygwin 2.9.0 (64-bit), compilation works fine, but there are 11 > > > test failures. > > Is it feasible to run these tests, particularly the Windows ones, on > the GNU make 4.3 release package? Sure. Find attached the results for GNU make 4.3 on the same Cygwin: 2 failu

Re: GNU make 4.3.91 on CentOS 8 Stream

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 see these failures among the output-sync tests. On a machine with minimal load. Bruno

Re: GNU make 4.3.91 on Debian 9.1

Paul Smith wrote: > *** Testing failed! Details saved in: makeerror-x86_64-pc-linux-gnu.tar.gz > *** Please report to > > make[3]: *** [Makefile:1537: check-regression] Error 1 > make[2]: *** [Makefile:1271: check-am] Error 2 > make[1]: *** [Makefile:973: check-recursive] Error 1 > m

Re: GNU make 4.3.92 on Debian 9.1

Martin Dorey wrote: > I looked into it further and concluded that failure is indeed expected on > Debian 9, where it's a harmless documentation of the legacy $(wildcard) > behavior with dangling symlinks there. GNU make 4.3.92, on the same machine, shows only this one failure: functions/wildcard

Re: GNU make 4.3.92 on Debian 11.1

I wrote: > On Debian 11.1 / x86_64 (a glibc 2.31 system) compilation succeeds > but there are 2 test failures. With GNU make 4.3.92, I see all tests pass.

Re: GNU make 4.3.92 on CentOS 8 Stream

I wrote: > On CentOS 8 Stream / x86_64 (a glibc 2.28 system), the compilation works fine, > but the test suite has failures in the 'output-sync' category: > - 3 failures in a build with gcc The same 3 failures still occur with GNU make 4.3.92. makeerror-x86_64-pc-linux-gnu-centos-8-stream.tar.

Re: GNU make 4.3.92 on Manjaro 17

I wrote: > On Manjaro Linux 17 (a glibc 2.28 system) in 64-bit mode, the compilation > works fine, but there are 2 test failures. With GNU make 4.3.92, all tests pass.

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

Paul Smith 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 just > assume that if we ca

Re: GNU make 4.3.92 on openSUSE Leap 15.2

I wrote: > On OpenSUSE Leap 15.2 / x86_64 (a glibc 2.26 system), the compilation works > fine > but 3 tests fail. On the same system, with GNU make 4.3.92, I see only 1 test failure: the wildcard tests. Due to the older glibc. makeerror-x86_64-pc-linux-gnu-opensuse15.2.tar.gz Description: appl

Re: GNU make 4.3.92 on FreeBSD

I wrote: > On FreeBSD 11 / x86, the compilation works fine but 1 test fails. On the same machine, with GNU make 4.3.92, all tests pass.

Re: GNU make 4.3.92 on Solaris 11

I wrote: > On Solaris 11.4 / x86_64, in 64-bit mode, the compilation works fine, but > there > are 20 test failures. Likewise in 32-bit mode. > > On Solaris 11 OmniOS, in 64-bit mode, the compilation works fine, but there > are 22 test failures. In 32-bit mode, even 26 test failures. > > On Sola

Re: GNU make 4.3.92 on GNU/Hurd

Paul Smith wrote: > 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 n

Re: GNU make 4.3.92 on mingw

I wrote: > On mingw (on Windows 10 in a Cygwin dev environment), compilation works > fine, but there are 91 test failures. With GNU make 4.3.92, this is down to 75 test failures. makeerror-x86_64-w64-mingw.tar.gz Description: application/compressed-tar

Re: GNU make 4.3.92 on Cygwin

I wrote: > On Cygwin 2.9.0 (64-bit), compilation works fine, but there are 11 test > failures. With GNU make 4.3.92, we're down to 10 test failures. makeerror-x86_64-pc-cygwin2.9.0.tar.gz Description: application/compressed-tar

Re: GNU Make 4.3.92 on OpenBSD 6.5

On OpenBSD 6.5, I see 6 test failures. makeerror-x86_64-unknown-openbsd6.5.tar.gz Description: application/compressed-tar

Re: GNU make 4.3.92 on Solaris 11

Dmitry Goncharov wrote: > > - On Solaris 11 OmniOS, there are only 3 test failures. Attached. > These are the same failures that you reported on centos. Indeed. > 10 s is so long, i suspect there is a deadlock. Possibly. Often the cause of a deadlock, in interprocess communication, is that a f

GNU make 4.4 on Solaris OpenIndiana

On Solaris 11 OpenIndiana 2022.10, building GNU make 4.4 produces different results depending on ABI: * In 64-bit mode (CC="gcc -m64 -O2"), all tests pass. * In 32-bit mode (CC="gcc -m32 -O2"), there are test failures in features/loadapi features/output-sync Find attached the log files tarbal

Re: GNU Make 4.4.0.90 on CentOS Stream

On CentOS stream, 3 tests fail, in the output-sync category. Find attached the logs: - with gcc: makeerror-4.4.0.90-x86_64-pc-linux-gnu-itaa.tar.gz - with clang: makeerror-4.4.0.90-x86_64-pc-linux-gnu-dzg1.tar.gz It looks similar to what I reported in https://lists.gnu.org/archive/html/bug-ma

Re: GNU Make 4.4.0.90 on Debian 11.1

On Debian 11.1 / x86_64 (a glibc 2.31 system) I don't see the older test failures from https://lists.gnu.org/archive/html/bug-make/2022-10/msg00124.html any more. But instead I see 4 test failures in the 'features/archives' category. Find the logs attached. makeerror-4.4.0.90-x86_64-pc-linux

Re: GNU Make 4.4.0.90 on Debian 9.1

On Debian 9.1.0 / x86 (a machine with glibc 2.24): - The wilcard.9 failure reported in https://lists.gnu.org/archive/html/bug-make/2022-10/msg00123.html and discussed in https://lists.gnu.org/archive/html/bug-make/2022-10/msg00158.html is still present. - The output-sync and temp_stdin fa

Re: GNU Make 4.4.0.90 on openSUSE Leap 15.2

On OpenSUSE Leap 15.2 / x86_64 (a glibc 2.26 system): - The wilcard.9 failure reported in https://lists.gnu.org/archive/html/bug-make/2022-10/msg00128.html and discussed in https://lists.gnu.org/archive/html/bug-make/2022-10/msg00158.html is still present. - The output-sync and temp_stdin

Re: GNU Make 4.4.0.90 on Manjaro 17 — bi-arch problem

On Manjaro Linux 17, installed from manjaro-kde-17.1.12-stable-x86_64.iso, in 32-bit mode, the build failure reported in https://lists.gnu.org/archive/html/bug-make/2022-10/msg00212.html still occurs. Find the build details attached. makeerror-manjaro17-32bit.tar.gz Description: application/co

Re: GNU Make 4.4.0.90 on Debian 11.1

Paul Smith wrote: > > But instead I see 4 test failures in the 'features/archives' > > category. > > These are because: > > ! /bin/sh: 1: cc: not found > > Why is there no C compiler on this system? Or is the problem that it's > not on the PATH for some reason? Indeed, there is no 'cc' nor '

Re: GNU Make 4.4.0.90 on GNU/Hurd

On GNU/Hurd (from 2022), I get 13 test failures: New: - 4 failures in category 'features/archives', due to "cc: not found". Already reported in https://lists.gnu.org/archive/html/bug-make/2022-10/msg00218.html : - 5 failures in category 'features/jobserver' - 2 failures in category 'featu

Re: GNU Make 4.4.0.90 on macOS 12

On macOS 12.5 / arm64 I see two test failures: - output-sync - temp_stdin Find attached the log files. The machine is gcc104.fsffrance.org. makeerror-4.4.0.90-aarch64-apple-darwin21.6.0-050w.tar.gz Description: application/compressed-tar

Re: GNU/Hurd installation

Paul Smith wrote: > I will download a GNU/Hurd KVM image, as suggested here: > > https://www.debian.org/ports/hurd/hurd-cd > > is that appropriate for testing? Yes. The GNU/Hurd installation instructions vary a bit over time, but these are my notes from 5 months ago. Fill in the ** fields.

Re: GNU/Hurd installation

Paul Smith wrote: > I've tried a couple of times, using different instructions (VirtualBox > and vanilla KVM) and every time when it starts to boot the first time > (after selecting this install) it prints: > > ... > module 0: initrd $(ramdisk-create) > rd0: 13279232 bytes @fa491 > mod

Re: GNU/Hurd installation

Paul Smith wrote: > > I'll try downloading the 2022-08-24 > > version you reference above and see if that makes a difference. > > It did not matter: same hang. There's clearly some magic pixie dust > that needs to be sprinkled on my system to get this to work, that I do > not have. Unfortunately

Re: GNU Make 4.4.0.90 on Solaris 11.4

The same 4 failures in features/archives ("cc: not found") also occur on Solaris 11.4. On this platform, 'cc' does not exist in $PATH, but 'gcc' does. Find attached the logs. makeerror-4.4.0.90-x86_64-pc-solaris2.11-q6is.tar.gz Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on Solaris 11 OmniOS

On Solaris 11 OmniOS, aside from the well-known 4 features/archives failures, I see 3 test failures in the 'features/output-sync' category. They come with an error message "timeout after 10 seconds". Here the logs: - 32-bit build: makeerror-4.4.0.90-x86_64-pc-solaris2.11-thix.tar.gz - 64-bit b

Re: GNU Make 4.4.0.90 on Solaris 11 OpenIndiana

On Solaris 11 OpenIndiana (from 2022), aside from the 4 well-known test failures in 'features/archives', in 64-bit mode I also see a test failure in category 'features/output-sync', with an error message "timeout after 10 seconds". I don't know why only this 1 out of 3 output-sync tests (compared

Re: GNU Make 4.4.0.90 on AIX 7.2

On AIX 7.2, in 64-bit mode, with the environment variables settings CC="xlc -q64 -qthreaded -qtls"; CXX="xlC -q64 -qthreaded -qtls"; AR="ar -X 64"; NM="nm -X 64 -B"; export CC CXX AR NM (with which I build many GNU packages successfully), I get 20 test failures: * 16 failures in catego

Re: GNU Make 4.4.0.90 on Cygwin

On Cygwin 2.9.0 (running in Windows 10), I see these test failures: * Same failures as seen in GNU/Hurd: - 5 failures in category 'features/jobserver' - 2 failures in category 'features/parallelism' - 1 failure in category 'features/recursion' - 1 failure in category 'functions/shell'

Re: GNU Make 4.4.0.90 on AIX 7.2

> * 1 failure in category 'features/include'. > The command 'touch -a test.foo' is being printed twice, not just once. > This could be a bug in the AIX exec* functions, which don't properly > separate the stdout and stderr of the parent process and child process > in some situations. (I had

Re: OpenIndiana installation

Paul Smith wrote: > I tried to install Solaris 11 OpenIndiana from an OVA file in > VirtualBox and I was able to get it to install but couldn't figure out > how to install a C compiler on it. Yes, every OS has its own type of package manager and, with it, its own way of finding out the actual pack

Re: CentOS Stream installation

Hi Paul, > It would be good to know whether you are testing CentOS Sream 8 or 9. I am testing CentOS 8 stream. Find my personal installation notes below. > I am not able to install CentOS Stream 9 in VirtualBox and get the > guest additions to work so I can mount a shared partition. Half the >

Re: CentOS Stream installation

Paul Smith wrote: > How many CPUs did you give to the VM? It shouldn't matter since we're > doing multiprocessing here but... maybe...? I was using 4G RAM and 4 > CPUs in my guest. I am using 1 CPU in that VM. > > I never install the VirtualBox guest additions. The downside is that > > sharing

Re: OpenIndiana installation

Paul Smith wrote: > I had a Solaris11 OVA and I ran the pkg > install developer/gcc-11 and it did lots of things but afterward there > was no gcc program installed (I searched the entire disk for "*gcc*"). > Weird. On Solaris 11 from Oracle, "pkg search /usr/bin/gcc" and "pkg search /usr/bin/g++"

Re: Regression on Cygwin: Problems with parallel make in 4.4

Ken Brown wrote: > I suggest > that you provide a configure option to set the jobserver style at the > time make is built, and set it to 'pipe' by default on Cygwin. And possibly also on GNU/Hurd. Cf. https://lists.gnu.org/archive/html/bug-make/2023-01/msg00107.html Bruno

Re: Regression on Cygwin: Problems with parallel make in 4.4

Paul Smith wrote: > > And possibly also on GNU/Hurd. Cf. > > https://lists.gnu.org/archive/html/bug-make/2023-01/msg00107.html > > I may be misremembering but I thought that you had tried forcing the > pipe jobserver option on GNU/Hurd and it didn't help. This must be a misunderstanding. I never

Re: GNU Make 4.4.0.90 on GNU/Hurd

I wrote: > On GNU/Hurd (from 2022), I get 13 test failures: > > New: > > - 4 failures in category 'features/archives', due to "cc: not found". > > Already reported in > https://lists.gnu.org/archive/html/bug-make/2022-10/msg00218.html : > > - 5 failures in category 'features/jobserver' >

Re: Regression on Cygwin: Problems with parallel make in 4.4

Paul Smith wrote: > I've made a change that causes GNU/Hurd to not use the mkfifo()-based > jobserver, and go back to using pipe(). That's nice, because compared to the previous results - 4 failures in category 'features/archives', due to "cc: not found". - 5 failures in category 'features/jo

Re: GNU Make 4.4.0.90 on GNU/Hurd

Paul Smith wrote: > > In other words, on GNU/Hurd, one should use 'glob' and 'globfree', > > not 'glob64' and 'globfree64'. Even though the libc is glibc and > > support for large files (> 2 GiB) is enabled. > > > > The culprit seems to be the glob.in.h file. > > As far as I can tell from the log

GNU Make 4.4.0.91 on GNU/Hurd

On GNU/Hurd, much fewer test failures than with 4.4.0.90 : Only 2 test failures, in category 'features/archives', due to "cc: not found". makeerror-4.4.0.91-i686-unknown-gnu0.9-0wnh.tar.gz Description: application/compressed-tar

GNU Make 4.4.0.91 on Cygwin

On Cygwin (running in Windows 10), the results are much better than those of 4.4.0.90 : All "Device or resource busy" failures are gone. Only the 1 failure in category 'misc/general4' is still present. makeerror-4.4.0.91-x86_64-

GNU Make 4.4.0.91 on AIX 7.2

On AIX 7.2 as well, the results are much better than for 4.4.0.90 : Only 3 test failures: - 2 from category 'features/archives', due to "cc: not found" - 1 from category 'features/include'. makeerror-4.4.0.91-powerpc-ibm-ai

Re: GNU Make 4.4.0.91 on AIX 7.2

Paul Smith wrote: > Does touch on AIX support the "-a" option? Yes. "-a" is a documented option of /usr/bin/touch, and it works fine. Bruno

GNU Make 4.4.0.91 on openSUSE Leap 15.2

On openSUSE Leap 15.2, the results are better than with 4.4.0.90 : - The wildcard.9 failure (well-known), - 2 failures in the 'features/archives' category, due to "cc: command not found". makeerror-4.4.0.91-x86_64-pc-linux-gnu

Re: GNU Make 4.4.0.91 on GNU/Hurd

Paul Smith wrote: > > Only 2 test failures, in category 'features/archives', due to "cc: > > not found". > > Argh, I forgot to change the CC thing everywhere in that test. I've > fixed this. > > You'll likely see this same issue with the other systems that don't > provide a "cc". Yes, I see the

GNU Make 4.4.0.91 on Solaris 11.4 (32-bit)

On Solaris 11.4 (32-bit mode): All 4 test failures in category 'features/archives', reported in , are still present. Somehow your fix for archives.12 and archives.13 does not work in this environment. I'm attaching the config.statu

Re: GNU Make 4.4.0.91 on GNU/Hurd

Paul Smith wrote: > > Yes, I see these also on: > > - Debian 11.1 > > - Solaris 11.4 (64-bit) > > - Solaris 11 OmniOS > > - Solaris 11 OpenIndiana > > The patch below should fix it but it's probably not worth the effort of > retesting all these systems. I've retested one of the systems: S

Re: GNU Make 4.4.0.91 on Solaris 11.4 (32-bit)

Paul Smith wrote: > > Somehow your fix for archives.12 and archives.13 does not work > > in this environment. I'm attaching the config.status. > > That test was accidentally running with 4.4.0.90 still: Oops, sorry. Retested Solaris 11.4 with your latest tests/scripts/features/archives patch. Re

GNU Make 4.4.0.91 on other platforms

All tests pass on: - Ubuntu 22.04 - CentOS 8 stream I.e. the 3 test failures reported in https://lists.gnu.org/archive/html/bug-make/2023-01/msg00097.html are gone. - CentOS Stream 9 - Manjaro 17 I.e. the bi-arch problem reported in https://lists.gnu.org/archive/html/bug

Re: GNU Make 4.4.0.91 on openSUSE Leap 15.2

Paul Smith wrote: > In the abstract it would be nice to have configure detect the bug in > glibc and use our local version of glob on those systems, but writing a > runtime test for the actual bug would be "interesting". gnulib/m4/glob.m4 contains a test for this bug: AC_CACHE_CHECK([whethe

GNU make troubleshooting

Hi all, In recent build system discussions on gnu-prog-discuss, the suggestion was made [1] to use GNU make's power instead of autoconf, automake, and POSIX make. I think GNU make is lacking transparency / debuggability / serviceability features before this suggestion makes sense. Especially for

Re: GNU make troubleshooting

> 2) Where is the Makefile source for each command that gets executed? >For each command that gets executed, print not only the command (or >nothing if the line begins with '@'), but also the location (which >Makefile, which line number). > >This would help in a number of situation

  1   2   >