[bug #63668] Default value of CXX on BSD OS's

[Brad Smith]

Follow-up Comment #4, bug #63668 (project make):

Thanks.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: GNU Make 4.4.0.91 on Cygwin

[Paul Smith]

On Sun, 2023-02-19 at 17:20 -0500, Ken Brown wrote:
> > Hm.  This is a test of this:
> > https://savannah.gnu.org/bugs/index.php?57674
> > 
> > which explicitly removes PATH from the environment completely.  It
> > should use a default PATH, which should mean "echo" works even so. 
> > I'm not really sure how this should react on a cygwin system, but I
> > guess since it behaves properly on Windows and POSIX it should work
> > on cygwin as well.  I'll have to figure out why only cygwin isn't
> > working.
> 
> All tests pass on my Cygwin 3.4.6 system.

Well... if it works with current releases I guess I don't feel like
spending a lot of time trying to suss out a very obscure issue (like
running make with no PATH set) on an older version of Cygwin.

Re: GNU Make 4.4.0.91 on openSUSE Leap 15.2

[Paul Smith]

On Sun, 2023-02-19 at 22:15 +0100, Bruno Haible wrote:
> gnulib/m4/glob.m4 contains a test for this bug:

Thanks!  I adapted this for GNU make and hopefully it will correctly
detect this issue.


# Check the system to see if it provides GNU glob.  If not, use our
# local version.  Also avoid versions of glibc which have symlink bug
# https://sourceware.org/bugzilla/show_bug.cgi?id=866 (test from gnulib)
AC_CACHE_CHECK([if system libc has working GNU glob], [make_cv_sys_gnu_glob],[
  if ln -s conf-doesntexist conf$$-globtest 2>/dev/null; then
make_check_symlink=yes
  else
make_check_symlink=no
  fi
  if test $cross_compiling = yes || test $make_check_symlink = no; then
# When cross-compiling or without symlink support, check the version
AC_COMPILE_IFELSE(
  [AC_LANG_PROGRAM(
[[#include 
  #include 
  #include 
  #include 
]],
[[
  #if _GNU_GLOB_INTERFACE_VERSION == 0
GNU glob not available in libc
  #elif __GLIBC__ < 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ < 27)
GNU glob in libc has dangling symlink bug
  #endif
]])],
  [make_cv_sys_gnu_glob=yes],
  [make_cv_sys_gnu_glob=no])
  else
# Check for GNU glob, and that it handles dangling symlinks properly
AC_RUN_IFELSE(
  [AC_LANG_PROGRAM(
[[#include 
  #include 
  #include 
  #include 
]],
[[
  #if _GNU_GLOB_INTERFACE_VERSION == 0
  return 1;
  #else
  glob_t found;
  if (glob ("conf*-globtest", 0, 0, ) == GLOB_NOMATCH)
return 1;
  globfree ();
  #endif
]])],
  [make_cv_sys_gnu_glob=yes],
  [make_cv_sys_gnu_glob=no],
  [dnl We don't get here.
   :
  ])
  fi
  test $make_check_symlink = no || rm -f conf$$-globtest
])

Re: GNU Make 4.4.0.91 on Cygwin

[Ken Brown]

On 2/19/2023 2:59 PM, Paul Smith wrote:

On Sun, 2023-02-19 at 20:32 +0100, Bruno Haible wrote:

All "Device or resource busy" failures are gone. Only the 1 failure
in category 'misc/general4' is still present.


Hm.  This is a test of this:
https://savannah.gnu.org/bugs/index.php?57674

which explicitly removes PATH from the environment completely.  It
should use a default PATH, which should mean "echo" works even so.  I'm
not really sure how this should react on a cygwin system, but I guess
since it behaves properly on Windows and POSIX it should work on cygwin
as well.  I'll have to figure out why only cygwin isn't working.


All tests pass on my Cygwin 3.4.6 system.

Ken

Re: GNU Make 4.4.0.91 on openSUSE Leap 15.2

[Bruno Haible]

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([whether glob lists broken symlinks],
 [gl_cv_glob_lists_symlinks],
[if test $cross_compiling != yes; then
   if ln -s conf-doesntexist conf$$-globtest 2>/dev/null; then
 gl_cv_glob_lists_symlinks=maybe
   else
 # If we can't make a symlink, then we cannot test this issue.  Be
 # pessimistic about this.
 gl_cv_glob_lists_symlinks=no
   fi
   if test $gl_cv_glob_lists_symlinks = maybe; then
 AC_RUN_IFELSE(
   [AC_LANG_PROGRAM(
  [[#include 
#include ]],
  [[glob_t found;
if (glob ("conf*-globtest", 0, NULL, ) == 
GLOB_NOMATCH)
  return 1;
globfree ();
  ]])],
   [gl_cv_glob_lists_symlinks=yes],
   [gl_cv_glob_lists_symlinks=no],
   [dnl We don't get here.
:
   ])
   fi
   rm -f conf$$-globtest
 else
   gl_cv_glob_lists_symlinks="$gl_cross_guess_normal"
 fi
])

GNU Make 4.4.0.91 on other platforms

[Bruno Haible]

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-make/2023-01/msg00101.html is fixed.

  - macOS 12.5
I.e. the 2 test failures reported in
https://lists.gnu.org/archive/html/bug-make/2023-01/msg00108.html are gone.

  - FreeBSD 11, NetBSD 9, OpenBSD 6.5

  - Solaris 10

Bruno

Re: GNU Make 4.4.0.91 on openSUSE Leap 15.2

[Paul Smith]

On Sun, 2023-02-19 at 21:23 +0100, Bruno Haible wrote:
> - The wildcard.9 failure (well-known),

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

However I think this is the bug:
  https://sourceware.org/bugzilla/show_bug.cgi?id=866

which says it was fixed in glibc 2.27.  So one way is to check:
   __GLIBC__ < 3 && __GLIBC_MINOR__ < 27
and that should detect it.

It seems OpenSUSE LEAP 15.0 was released in May 2018 and glibc 2.27 was
released in Feb 2018 so it's likely 15.0 was using a glibc older than
2.27, and I guess the point releases have never updated to a newer
version nor pulled this fix back as a patch.

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

[Bruno Haible]

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.
Results:
  - 64 bit: All tests pass.
  - 32 bit: All tests pass.

Yeah!

Bruno

Re: GNU Make 4.4.0.91 on GNU/Hurd

[Bruno Haible]

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: Solaris 11.4 (64-bit).
Your patch fixes the two remaining test failures. Now, all tests pass.

Bruno

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

[Paul Smith]

On Sun, 2023-02-19 at 21:53 +0100, Bruno Haible 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:

  # 
/export/home/bruno/make-4.4.0.90/build-32/tests/scripts/features/archives:257:
  /export/home/bruno/make-4.4.0.90/build-32/tests/../make -f 
work/features/archives.mk.8 AR=ar

Note, the test tarball I create already contains config.status so no
need to send it separately (but thanks!)

GNU Make 4.4.0.91 on Solaris 11.4 (32-bit)

[Bruno Haible]

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



makeerror-4.4.0.90-x86_64-pc-solaris2.11-avnc.tar.gz
Description: application/compressed-tar


config.status
Description: application/shellscript

Re: GNU Make 4.4.0.91 on GNU/Hurd

[Paul Smith]

On Sun, 2023-02-19 at 21:46 +0100, Bruno Haible wrote:
> > You'll likely see this same issue with the other systems that don't
> > provide a "cc".
> 
> 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.


--- a/tests/scripts/features/archives
+++ b/tests/scripts/features/archives
@@ -265,16 +265,16 @@ mylib.a: mylib.a(a.o b.o)
 !,
   $vars, "Compile a.c\nCompile b.c\n$ar $arflags mylib.a a.o 
b.o\n${create2}rm b.o a.o");

-run_make_test(undef, $arvar, "#MAKE#: 'mylib.a' is up to date.");
+run_make_test(undef, $vars, "#MAKE#: 'mylib.a' is up to date.");

 # Now update one of the source files and it should be compiled and archived

 sleep(2);
 touch('b.c');

-run_make_test(undef, $arvar, "Compile b.c\n$ar $arflags mylib.a b.o\n${add2}rm 
b.o");
+run_make_test(undef, $vars, "Compile b.c\n$ar $arflags mylib.a b.o\n${add2}rm 
b.o");

-run_make_test(undef, $arvar, "#MAKE#: 'mylib.a' is up to date.");
+run_make_test(undef, $vars, "#MAKE#: 'mylib.a' is up to date.");

 unlink('a.c', 'b.c', 'a.o', 'b.o', 'mylib.a');
 }

Re: GNU Make 4.4.0.91 on GNU/Hurd

[Bruno Haible]

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 these also on:
  - Debian 11.1
  - Solaris 11.4 (64-bit)
  - Solaris 11 OmniOS
  - Solaris 11 OpenIndiana

Bruno

Re: GNU Make 4.4.0.91 on AIX 7.2

[Paul Smith]

On Sun, 2023-02-19 at 21:20 +0100, Bruno Haible wrote:
> 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.

Hm.  Maybe the AIX filesystem has issues with subsecond timestamps, or
something.  If you have the bandwidth can you apply this patch and see
if you still get that failure:


--- a/tests/scripts/features/include
+++ b/tests/scripts/features/include
@@ -476,14 +476,16 @@ all: ;
 # Test that included makefiles are not intermediate.
 # Here 'test.foo' is mentioned explicitly and cannot be considered
 # intermediate.
-('test.foo', 'test.x', 'test');
+utouch(-10, 'test.foo');
+utouch(-5, 'test.x');
+touch('test');
 run_make_test(q!
 .PHONY: force
 include test.foo
-%.foo: force; touch -a $@
+%.foo: force; @echo force $@
 %.x: %.foo; touch $@
 test: test.x; touch $@
-!, '', "touch -a test.foo\n#MAKE#: 'test' is up to date.\n");
+!, '', "force test.foo\n#MAKE#: 'test' is up to date.\n");

 unlink('test.foo', 'test.x', 'test');

GNU Make 4.4.0.91 on openSUSE Leap 15.2

[Bruno Haible]

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-ex0u.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.91 on AIX 7.2

[Bruno Haible]

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

Re: GNU Make 4.4.0.91 on AIX 7.2

[Paul Smith]

On Sun, 2023-02-19 at 20:55 +0100, Bruno Haible wrote:
>   - 1 from category 'features/include'.

Hm.  I don't know what the problem is here; clearly we shouldn't be
printing this line twice:

*** work/features/include.base.37   Sun Feb 19 19:38:21 2023
--- work/features/include.log.37Sun Feb 19 19:38:21 2023
***
*** 1,2 
--- 1,3 
  touch -a test.foo
+ touch -a test.foo
  make: 'test' is up to date.

I wonder if it's related to the "touch -a" option.  We don't use that
anywhere else that I know of.  Does touch on AIX support the "-a"
option?

Re: GNU Make 4.4.0.91 on Cygwin

[Paul Smith]

On Sun, 2023-02-19 at 20:32 +0100, Bruno Haible wrote:
> All "Device or resource busy" failures are gone. Only the 1 failure
> in category 'misc/general4' is still present.

Hm.  This is a test of this:
https://savannah.gnu.org/bugs/index.php?57674

which explicitly removes PATH from the environment completely.  It
should use a default PATH, which should mean "echo" works even so.  I'm
not really sure how this should react on a cygwin system, but I guess
since it behaves properly on Windows and POSIX it should work on cygwin
as well.  I'll have to figure out why only cygwin isn't working.

[bug #63818] V=1 stopped working for Linux kernel module builds with make-4.4

[Martin Dorey]

URL:
  

 Summary: V=1 stopped working for Linux kernel module builds
with make-4.4
   Group: make
   Submitter: mdorey
   Submitted: Sun 19 Feb 2023 11:59:36 AM PST
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 19 Feb 2023 11:59:36 AM PST By: Martin Dorey 
As reported by Jan Palus in
https://lists.gnu.org/archive/html/bug-make/2022-11/msg00185.html with the
diagnosis polished by Paul in reply, the Linux kernel build system goes into
silent mode, stopping V=1 from telling you eg about the compiler commands,
with make-4.4 (but not earlier), if an s is present in certain parts of the
command line.  When compiling modules, this is more likely than it might seem,
because an argument of the form M=$(CURDIR) is given to make and s is common
in directory names.

This was fixed in the Linux kernel build system by Dmitry with help from
Masahiro Yamada for v6.2-rc1
(https://github.com/torvalds/linux/commit/4bf73588165ba7d32131a043775557a54b6e1db5).
 I think the problem arrived with v4.13-rc1
(https://github.com/torvalds/linux/commit/6f0fa58e459642b16901521cc58ac474b787ec5b).
 To put that in Debian terms, that means that Buster, Bullseye and (likely)
Bookworm are afflicted.

Here's a complete example, derived from https://sysprog21.github.io/lkmpg/ but
with the Makefile simplified the way I would have written it and a stray quote
left deliberately at the end of the .c file:


martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$ cat Makefile
obj-m += hello-1.o 

KVERSION ?= $(shell uname -r)
KVERSION := $(KVERSION)

TARGETS = modules clean
.PHONY: $(TARGETS)
$(TARGETS): %:; $(MAKE) -C /lib/modules/$(KVERSION)/build M=$(CURDIR) $@
martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$ cat hello-1.c 
/* 
 * hello-1.c - The simplest kernel module. 
 */ 
#include  /* Needed for pr_info() */ 
#include  /* Needed by all modules */ 
 
int init_module(void) 
{ 
pr_info("Hello world 1.\n"); 
 
/* A non 0 return means init_module failed; module can't be loaded. */ 
return 0; 
} 
 
void cleanup_module(void) 
{ 
pr_info("Goodbye world 1.\n"); 
} 
 
MODULE_LICENSE("GPL");
"
martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$ 


This is what the problem looks like:


martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$
~/download/make-4.4/make V=1
/home/martind/download/make-4.4/make -C /lib/modules/4.19.0-21-amd64/build
M=/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s modules
make[1]: Entering directory '/usr/src/linux-headers-4.19.0-21-amd64'
/home/martind/download/make-4.4/make -C /usr/src/linux-headers-4.19.0-21-amd64
KBUILD_SRC=/usr/src/linux-headers-4.19.0-21-common \
-f /usr/src/linux-headers-4.19.0-21-common/Makefile modules
mkdir -p /home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/.tmp_versions ; rm
-f /home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/.tmp_versions/*
/home/martind/download/make-4.4/make -f
/usr/src/linux-headers-4.19.0-21-common/scripts/Makefile.build
obj=/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s
(cat /dev/null;   echo
kernel//home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/hello-1.ko;) >
/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/modules.order
/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/hello-1.c:21:1: warning:
missing terminating " character
 "
 ^
/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/hello-1.c:21:1: error:
missing terminating " character
make[4]: ***
[/usr/src/linux-headers-4.19.0-21-common/scripts/Makefile.build:315:
/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/hello-1.o] Error 1
make[3]: *** [/usr/src/linux-headers-4.19.0-21-common/Makefile:1561:
_module_/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s] Error 2
make[2]: *** [Makefile:146: sub-make] Error 2
make[1]: *** [Makefile:8: all] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.19.0-21-amd64'
make: *** [Makefile:8: modules] Error 2
martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$ 


The one new piece of information I want to present with this not-really-a-bug
report is the work around of adding quiet= to the command line, which then
adds the gcc line to the output:


martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$
~/download/make-4.4/make V=1 quiet=
/home/martind/download/make-4.4/make -C /lib/modules/4.19.0-21-amd64/build
M=/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s modules
make[1]: Entering directory '/usr/src/linux-headers-4.19.0-21-amd64'

GNU Make 4.4.0.91 on AIX 7.2

[Bruno Haible]

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-aix7.2.4.0-h67e.tar.gz
Description: application/compressed-tar


makeerror-4.4.0.91-powerpc-ibm-aix7.2.4.0-oo5n.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.91 on GNU/Hurd

[Paul Smith]

On Sun, 2023-02-19 at 20:25 +0100, Bruno Haible wrote:
> 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".

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

GNU Make 4.4.0.91 on Cygwin

[Bruno Haible]

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-pc-cygwin-gcml.tar.gz
Description: application/compressed-tar

GNU Make 4.4.0.91 on GNU/Hurd

[Bruno Haible]

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 release candidate available

[Paul Smith]

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/


A new release candidate for GNU make 4.4.1 is available now for download:

  3a691c559bd2f831317da8974a5e800b  make-4.4.0.91.tar.gz
  c0a9d14db4578262818dc8635c53fd52  make-4.4.0.91.tar.lz

You can obtain a copy from:  https://alpha.gnu.org/gnu/make/

- NEWS 

Version 4.4.0.91 (19 Feb 2023)

This release is primarily a bug-fix release.
A complete list of bugs fixed in this version is available here:

https://sv.gnu.org/bugs/index.php?group=make_id=111_release_id=110=custom

* WARNING: Backward-incompatibility!
  In previous releases it was not well-defined when updates to MAKEFLAGS made
  inside a makefile would be visible.  This release ensures they are visible
  immediately, even when invoking $(shell ...) functions.  Also, command line
  variable assignments are now always present in MAKEFLAGS, even when parsing
  makefiles.
  Implementation provided by Dmitry Goncharov 

* New feature: Parallel builds of archives
  Previously it was not possible to use parallel builds with archives.  It is
  still not possible using the built-in rules, however you can now override
  the built-in rules with a slightly different set of rules and use parallel
  builds with archive creation.  See the "Dangers When Using Archives" section
  of the GNU Make manual, and https://savannah.gnu.org/bugs/index.php?14927

* New platform: GNU Make is supported on z/OS
  Thanks to Igor Todorovski  for the patches and testing
  assistance.

* Previously target-specific variables would inherit their "export" capability
  from parent target-specific variables even if they were marked private.  Now
  private parent target-specific variables have no affect.  For more details
  see https://savannah.gnu.org/bugs/index.php?61463

* Updates to allow building on OS/2
  Provided by KO Myung-Hun 

* Disable FIFO jobserver on GNU/Hurd and Cygwin
  Experimentation shows that the new FIFO-based jobserver doesn't work well on
  GNU/Hurd or Cygwin: revert these systems to use the pipe-based jobserver.



signature.asc
Description: This is a digitally signed message part

Re: GNU Make 4.4.0.90 on GNU/Hurd

[Bruno Haible]

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 logging you sent, GNU make has correctly
> detected that the system library is glibc and so it will not use any
> part of the internal globbing library, including the glob.in.h file.
> 
> In other words, there should be no glob.h file in the GNU make build
> directories and the glob.h that read.c includes should be the system
> glob.h, and there will be no glob.o added to the libgnu.a library.

You're entirely right.

> If I'm right, then the error you're seeing must come from the system's
> glob implementation, somehow.

Yes. Reported as a glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=30146

Bruno

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

[Ken Brown]

On 2/19/2023 9:29 AM, Paul Smith wrote:

On Sun, 2023-02-19 at 09:17 -0500, Ken Brown wrote:

So I'm not sure where to go from here on Cygwin.  Should I force
Cygwin builds to use the "pipe" jobserver, as I've done for
GNU/Hurd?


My preference would be for you to provide a configure option, which
defaults to "pipe" on Cygwin.  But if you don't want to do that, then
I think you should force Cygwin builds to use "pipe".


There is (in my current implementation, not released yet) a way to do
that but it's a little obscure; you need to use:

  ./configure CPPFLAGS=-DJOBSERVER_USE_FIFO=0

or

  ./configure CPPFLAGS=-DJOBSERVER_USE_FIFO=1


That's good.


If you set it explicitly then that setting is obeyed regardless of the
capabilities of the system (well, if mkfifo() is not available then
trying to enable it is a no-op of course).


Should I add preprocessor checks (or autoconf checks?) to try to
figure out which version of Cygwin is being used and choose based
on that?  I don't know how to check versions.


That wouldn't help.  There's currently no known version of Cygwin on
which the fifo option works well.  (Bruno tested on old version, I
tested the current version.)


OK but I noted you said:


If I simply run 'make -j13 world' without using the Build script, it
doesn't hang.


so I wasn't sure if we were considering that a "full failure".


I agree that it's not a full failure, but it's annoying when it happens. 
 In my use case (building TeX Live using the supplied Build script), 
the build runs for about 2 hours before it fails.



 I guess
if we don't know why it happens, we just have to disable mkfifo().

I will change the default setting of the jobserver to use "pipe" on
Cygwin, at least for now.


Thanks.

Ken

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

[Paul Smith]

On Sun, 2023-02-19 at 09:17 -0500, Ken Brown wrote:
> > So I'm not sure where to go from here on Cygwin.  Should I force
> > Cygwin builds to use the "pipe" jobserver, as I've done for
> > GNU/Hurd?
> 
> My preference would be for you to provide a configure option, which 
> defaults to "pipe" on Cygwin.  But if you don't want to do that, then
> I think you should force Cygwin builds to use "pipe".

There is (in my current implementation, not released yet) a way to do
that but it's a little obscure; you need to use:

 ./configure CPPFLAGS=-DJOBSERVER_USE_FIFO=0

or

 ./configure CPPFLAGS=-DJOBSERVER_USE_FIFO=1

If you set it explicitly then that setting is obeyed regardless of the
capabilities of the system (well, if mkfifo() is not available then
trying to enable it is a no-op of course).

> > Should I add preprocessor checks (or autoconf checks?) to try to
> > figure out which version of Cygwin is being used and choose based
> > on that?  I don't know how to check versions.
> 
> That wouldn't help.  There's currently no known version of Cygwin on 
> which the fifo option works well.  (Bruno tested on old version, I 
> tested the current version.)

OK but I noted you said:

> If I simply run 'make -j13 world' without using the Build script, it
> doesn't hang.

so I wasn't sure if we were considering that a "full failure".  I guess
if we don't know why it happens, we just have to disable mkfifo().

I will change the default setting of the jobserver to use "pipe" on
Cygwin, at least for now.

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

[Ken Brown]

On 2/19/2023 8:49 AM, Paul Smith wrote:

On Wed, 2023-02-15 at 13:57 -0500, Ken Brown wrote:

One thing to keep in mind here is that your tests on Cygwin were done
on Cygwin 2.9.0, in which FIFOs were very poorly supported.  For
example, a FIFO couldn't have multiple readers or writers.  If
GNU/Hurd has similar limitations, that could explain the similar test
results.

Cygwin's FIFO implementation was completely rewritten starting with
3.0, and it now supports multiple readers and writers.  So the issue
with current Cygwin is more likely a bug in Cygwin and/or make.


GNU make _definitely_ has multiple readers/writers (that's really the
whole point :)).

So I'm not sure where to go from here on Cygwin.  Should I force Cygwin
builds to use the "pipe" jobserver, as I've done for GNU/Hurd?


My preference would be for you to provide a configure option, which 
defaults to "pipe" on Cygwin.  But if you don't want to do that, then I 
think you should force Cygwin builds to use "pipe".



 Should
I add preprocessor checks (or autoconf checks?) to try to figure out
which version of Cygwin is being used and choose based on that?  I
don't know how to check versions.


That wouldn't help.  There's currently no known version of Cygwin on 
which the fifo option works well.  (Bruno tested on old version, I 
tested the current version.)


Ken

Re: pattern rules with multiple targets producing intermediate files

[Paul Smith]

On Tue, 2023-02-07 at 14:51 +0100, Jan Beulich wrote:
> while something has changed from 4.3 to 4.4 in the dealing with
> intermediate files, the example Makefile below still doesn't work
> as expected. There are two pairs of *.[ch] files generated, each by
> their respective rule. Each of the *.o files to be compiled from the
> *.c ones has a dependency recorded on both *.h files. If (up-to-date
> or outdated) instances of all four generated files are there, all is
> fine. If both *.c files are missing, all is fine as well. However,
> if only one *.c file is missing and the other is up-to-date,
> compilation of the other *.c file will (provided at least -j2 was
> passed) be invoked in parallel to the re-generation of the other
> *.[ch] pair, not taking into consideration that one of the *.h files
> is in the process of being re-generated (together with its sibling
> *.c file).

Hi Jan.

Unfortunately the above is hard for me to understand and trying to
reproduce the behavior you're concerned about with the makefile you
provided didn't yield success.

It would be very helpful if you could (A) explain how to set up the
environment (I assume I need to "touch tst_a.a tst_b.b"?  Anything
else?), (B) show a transcript of the commands you ran and the output
you got, cut and pasted, and (C) point out very clearly in the output
which things you think are not correct, and what you expected to happen
instead.

Thanks!

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

[Paul Smith]

On Wed, 2023-02-15 at 13:57 -0500, Ken Brown wrote:
> One thing to keep in mind here is that your tests on Cygwin were done
> on Cygwin 2.9.0, in which FIFOs were very poorly supported.  For
> example, a FIFO couldn't have multiple readers or writers.  If
> GNU/Hurd has similar limitations, that could explain the similar test
> results.
> 
> Cygwin's FIFO implementation was completely rewritten starting with
> 3.0, and it now supports multiple readers and writers.  So the issue
> with current Cygwin is more likely a bug in Cygwin and/or make.

GNU make _definitely_ has multiple readers/writers (that's really the
whole point :)).

So I'm not sure where to go from here on Cygwin.  Should I force Cygwin
builds to use the "pipe" jobserver, as I've done for GNU/Hurd?  Should
I add preprocessor checks (or autoconf checks?) to try to figure out
which version of Cygwin is being used and choose based on that?  I
don't know how to check versions.

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

[Paul Smith]

On Sun, 2023-02-19 at 12:44 +0100, Bruno Haible wrote:
>   - 4 failures in category 'features/jobserver'
>   - 2 failure in category 'functions/shell'

I looked at the error logging you sent, and I think these are just a
result of an incomplete/incorrect setting of the default value to
"pipe".  Hopefully the next release candidate, with the full
implementation, won't see them.

Re: GNU Make 4.4.0.90 on GNU/Hurd

[Paul Smith]

On Sun, 2023-02-19 at 12:34 +0100, Bruno Haible 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 logging you sent, GNU make has correctly
detected that the system library is glibc and so it will not use any
part of the internal globbing library, including the glob.in.h file.

In other words, there should be no glob.h file in the GNU make build
directories and the glob.h that read.c includes should be the system
glob.h, and there will be no glob.o added to the libgnu.a library.

Unfortunately the error logging I generate on failure can't include a
full transcript of the compilation step, to check this.

If I'm right, then the error you're seeing must come from the system's
glob implementation, somehow.

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

[Bruno Haible]

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/jobserver'
  - 2 failures in category 'features/parallelism'
  - 1 failure in category 'features/recursion'
  - 1 failure in category 'functions/shell'

with a default jobserver_style = "pipe", I get

  - 4 failures in category 'features/archives', due to "cc: not found".
  - 4 failures in category 'features/jobserver'
  - 2 failure in category 'functions/shell'

Bruno


makeerror-4.4.0.90-i686-unknown-gnu0.9-aonj.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on GNU/Hurd

[Bruno Haible]

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'
>   - 2 failures in category 'features/parallelism'
>   - 1 failure in category 'features/recursion'
>   - 1 failure in category 'functions/shell'

Note that on this platform, the build log has a warning:

gcc-12  -g -O2 -Wl,--export-dynamic -L/home/bruno/lib -o make src/ar.o 
src/arscan.o src/commands.o src/default.o src/dir.o src/expand.o src/file.o 
src/function.o src/getopt.o src/getopt1.o src/guile.o src/hash.o src/implicit.o 
src/job.o src/load.o src/loadapi.o src/main.o src/misc.o src/output.o 
src/read.o src/remake.o src/rule.o src/shuffle.o src/signame.o src/strcache.o 
src/variable.o src/version.o src/vpath.o  src/posixos.o  src/remote-stub.o   
lib/libgnu.a   
/usr/bin/ld: src/read.o: in function `parse_file_seq':
/home/bruno/make-4.4.0.90/build/../src/read.c:3472: warning: glob64 is not 
implemented and will always fail

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.

Bruno