Re: MAKEFLAGS=-r

Dmitry Goncharov wrote: > On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible wrote: > > And finally, MAKEFLAGS is not even mentioned in the main index of the GNU > > Make > > documentation [5], and only regarding "recursion" in the Variables index > > [6]. &g

Re: MAKEFLAGS=-r

Dmitry Goncharov wrote: > > If a Makefile uses MAKEFLAGS=-r and > > the Makefile in a subdirectory needs built-in rules, will the MAKEFLAGS=-r > > setting propagate to the subdirectory? > > It will. Ouch. This is usually undesired, since a developer works on one Makefile at a time. Together

Re: disabling the built-in rules

Paul Smith wrote: > POSIX > reserves all targets prefixed with "." (that are not already specified > in the standard) to the implementation. So it's fine with POSIX to add > a pseudo target like .NOBUILTINS; no conforming makefile can use that > target for anything else. Thanks for explaining!

Re: disabling the built-in rules

Paul Smith wrote: > Or, to test: > > all: > > .SUFFIXES: > %:: %,v > %:: RCS/%,v > %:: RCS/% > %:: s.% > %:: SCCS/s.% Indeed, this works fine with the 'make' on FreeBSD, NetBSD, OpenBSD, Solaris 10, and AIX. > If we were to add something it would be a pseudo-target like: > >

Re: disabling the built-in rules

Paul Smith wrote: > I do not > usually recommend this method of clearing the default rules. There are > issues with modifying MAKEFLAGS, especially with some older versions of > GNU Make. And also, in some older versions setting MAKEFLAGS in the > makefile doesn't actually take effect anyway: it

Re: MAKEFLAGS=-r

David Boyce wrote: > You say GNUMAKEFLAGS+=-r is "invalid syntax" but I don't know quite how to > read that. It's not invalid in the sense of causing an error, it's just > that it would be invisible to any non-GNU make program Indeed, sorry. You're right. I confused it with the := assignment

Re: MAKEFLAGS=-r

David Boyce wrote: > Everything else aside, there's a profound difference between MAKEFLAGS=-r > and MAKEFLAGS+=-r. The latter is far less destabilizing. At least the '-n' option does not get lost by MAKEFLAGS=-r. That is, setting MAKEFLAGS=-r and running 'make -n' does not cause the actions to

Re: GNU make troubleshooting

Dmitry Goncharov wrote: > > I believe these two user goals are so different; they belong in different > > chapters. > ... > In other words, i don't see a chapter on how to avoid big debug output > without optimizing the makefile. Wait a second. "How to avoid big debug output?" is not one of the

Re: MAKEFLAGS=-r

Dmitry Goncharov wrote: > Once the makefile author knows the makefile does not need built-in > rules, they should add MAKEFLAGS=-r in the makefile and > this will do a good service to all their users. The premise "does not need built-in rules" is likely true for most Makefiles generated by GNU

Re: GNU make troubleshooting

Dmitry Goncharov wrote: > > 1) The title, and what does the user want? > This patch is not a full-fledged troubleshooting guide. ... > > Is that really what I want to do and should do, as a user? > i believe, makefile authors should apply these techniques. OK, then it's appropriate to create

Re: GNU make troubleshooting

Hello Dmitry, Dmitry Goncharov wrote: > >I tried -d a couple of times, and it produced a ton of output, that > >was too much for me to make sense of. Probably 10% to 20% of the > >developers in general have trace filtering skills, that is, know how > >to extract the essential

Re: GNU make troubleshooting

Alejandro Colomar wrote: > In GNU Make, the "printf" statement is the > $(info ...) function. Maybe you didn't know about it? Correct, I did not know about it. I created a 'dummy' target with an echo command... It would be really useful to collect all these various troubleshooting tricks in a

Re: GNU make troubleshooting

Paul Smith wrote: > > I get the same output with GNU make 4.4 as with 4.3. > > Apologies for my mistake: I'm using the latest release (4.4.1). > I tried your test: > > $ make --trace mbrtoc32.o > Makefile:1752: update target 'mbrtoc32.o' due to: target does not exist With 4.4.1, I see this

Re: GNU make troubleshooting

Paul Smith wrote: > Maybe a version difference. I'm using 4.4. I get the same output with GNU make 4.4 as with 4.3. Bruno

Re: GNU make troubleshooting

Paul Smith wrote: > Showing the "macroexpanded make sources" is difficult because make > doesn't just expand an entire line then parse it. Makefile syntax is > context-sensitive so you can't know how or if to expand parts of a line > until you've already expanded other parts. Of course make

Re: GNU make troubleshooting

Paul Smith wrote: > It's not acceptable (to me) to only show the one newest file, not all > files that are newer than the target, because often you want to know > all the newer files. You say "It's not acceptable (to me) to only show the one newest file", and I say "A tool that shows me 3.7 KB

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

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 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:

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

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 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:

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

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

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

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

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.

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:

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

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

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: > > 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: 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: 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: 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: 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: 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

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

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

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

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

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

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 >

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

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 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:

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

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

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.

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

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

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 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 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 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 not set any

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

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 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:

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

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

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 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:

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 >

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

[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

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

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

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

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\"

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

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

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

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

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

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

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

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]

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

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

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

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

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

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

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

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 >

  1   2   >