make 3.81: showing time differences

[Bruno Haible]

Hi,

With GNU make 3.81 the following warnings were seen:

make[5]: Warning: File `.deps/test-xvasprintf.Po' has modification time 4.8e+02 
s in the future
make[2]: Warning: File `Makefile' has modification time 1.1e+02 s in the future
make[1]: Warning: File `Makefile' has modification time 95 s in the future

The notation "4.8e+02 s" is a quite obfuscated way to express "4 minutes".

I'm not asking for conversion of the duration to days, hours, minutes, and
seconds. Just using fixed-point notation instead of exponential notation
is enough: "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]>

* remake.c (f_mtime): Print time difference values between 100 and
ULONG_MAX in fixed-point notation rather than in exponention notation.

--- make-3.81/remake.c.bak  2006-03-20 03:36:37.0 +0100
+++ make-3.81/remake.c  2007-10-27 22:08:54.0 +0200
@@ -1310,8 +1310,13 @@
 (FILE_TIMESTAMP_S (mtime) - FILE_TIMESTAMP_S (now)
  + ((FILE_TIMESTAMP_NS (mtime) - FILE_TIMESTAMP_NS (now))
 / 1e9));
-  error (NILF, _("Warning: File `%s' has modification time %.2g s 
in the future"),
- file->name, from_now);
+ char from_now_string[100];
+ if (from_now >= 99 && from_now <= ULONG_MAX)
+   sprintf (from_now_string, "%lu", (unsigned long) from_now);
+ else
+   sprintf (from_now_string, "%.2g", from_now);
+  error (NILF, _("Warning: File `%s' has modification time %s s in 
the future"),
+ file->name, from_now_string);
 #endif
   clock_skew_detected = 1;
 }



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

make -q and phony targets

[Bruno Haible]

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

$ make --version | head -n 1
GNU Make 3.82
$ make
echo > foo
$ make
$ echo $?
0
$ make -q
$ echo $?
1

More details what's going on:

$ make -q -d
...
 No implicit rule found for `all'.
  Considering target file `sanity'.
   File `sanity' does not exist.
   Finished prerequisites of target file `sanity'.
  Must remake target `sanity'.
Invoking recipe from Makefile:4 to update target `sanity'.
  Target file `sanity' needs remade under -q.
 Finished prerequisites of target file `all'.
Giving up on target file `all'.

It fails because "Target file `sanity' needs remade under -q".

But I told 'make' already through the .PHONY target that the 'sanity' target
has nothing to do with the file system and serves only the purpose to give
some structure to the Makefile.

Please, can you change the way '.PHONY' targets are considered for "make -q"?

Or, if not, Paul Eggert's suggestion [1] is to invent a new special built-in
target for this purpose.

Bruno

PS: Please let me know if I should have written into the bug tracker instead
of to the mailing list.

[1] http://lists.gnu.org/archive/html/bug-gnulib/2011-08/msg00107.html
-- 
In memoriam Paul Richter 

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Bruno Haible]

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:
> 
> #: file.c:412
> msgid "Removing intermediate files...\n"
> msgstr "Die übergangsweise angelegte Datei „%s“ wird gelöscht...\n"
> 
> Ich würde mich freuen wenn diese korrigiert würde.
> 
> Mit freundlichen Grüßen
> Florian Zeitz

He's saying that 'make' crashed because of this translation. It can
be found in the make/de.po file of GNU make 4.1 and newer.

The workflow with PO files is designed in such a way that even if
translators make a mistake like this (providing a translation with %s
for a string that doesn't contain %s), "msgfmt -c" will catch it.
BUT "msgfmt -c" makes this check only for a message marked with
'#, c-format':

  de.po:272: number of format specifications in 'msgid' and 'msgstr' does not 
match
  msgfmt: found 1 fatal error

The question thus is: Why was this message not marked with '#, c-format'
in the make.pot file? The answer is: because it is an argument to the
macro DB (defined in debug.h), and xgettext doesn't know that DB behaves
like printf.

Compare the results of
  $ xgettext -o - --keyword=_ --keyword=N_ file.c
and
  $ xgettext -o - --keyword=_ --keyword=N_ --flag=DB:2:c-format file.c

So, the problem will be fixed if you add the option
  --flag=DB:2:c-format
to the variable XGETTEXT_OPTIONS in the file po/Makevars.

Regards,

  Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

make-3.79 on BeOS

[Bruno Haible]

Hi,

When compiling make-3.79 on BeOS, I encountered the following problems:

1) Compilation error in arscan.c. BeOS doesn't have the  header file.
But it has archive libraries, and uses the GNU binutils to create them.
I therefore copied the contents of glibc's  into arscan.c, and
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/arscan.c Sat Jan 22 06:43:03 2000
--- make-3.79/arscan.c  Sun Apr 16 01:38:13 2000
***
*** 232,238 
  #endif
  
  #ifndef WINDOWS32
! # include 
  #else
  /* These should allow us to read Windows (VC++) libraries (according to Frank
   * Libbrecht <[EMAIL PROTECTED]>)
--- 232,255 
  #endif
  
  #ifndef WINDOWS32
! # ifndef __BEOS__
! #  include 
! # else
!/* BeOS 5 doesn't have  but has archives in the same format
! * as many other Unices.  */
! #  define ARMAG   "!\n" /* String that begins an archive file.  */
! #  define SARMAG  8   /* Size of that string.  */
! #  define ARFMAG  "`\n"   /* String in ar_fmag at end of each header.  */
! struct ar_hdr
!   {
! char ar_name[16]; /* Member file name, sometimes / terminated. */
! char ar_date[12]; /* File date, decimal seconds since Epoch.  */
! char ar_uid[6], ar_gid[6];/* User and group IDs, in ASCII decimal.  */
! char ar_mode[8];  /* File mode, in ASCII octal.  */
! char ar_size[10]; /* File size, in ASCII decimal.  */
! char ar_fmag[2];  /* Always contains ARFMAG.  */
!   };
! # endif
  #else
  /* These should allow us to read Windows (VC++) libraries (according to Frank
   * Libbrecht <[EMAIL PROTECTED]>)


2) Error during "make distclean":

./configure
make
make install
make distclean
breaks as follows:

$ make distclean
Making distclean in .
make[1]: Entering directory `/bework/gnubuild/make-3.79'
rm -f config.h
rm -f *.tab.c
rm -f TAGS ID
rm -f Makefile build.sh
rm -f config.cache config.log stamp-h stamp-h[0-9]*
test -z "make" || rm -f make
test -z "loadavg" || rm -f loadavg
rm -f *.o core *.core
rm -f make.aux make.cp make.cps make.dvi make.fn make.fns make.ky \
  make.kys make.ps make.log make.pg make.toc make.tp make.tps \
  make.vr make.vrs make.op make.tr make.cv make.cn
test -z "loadavg.c" || rm -f loadavg.c
make[1]: Leaving directory `/bework/gnubuild/make-3.79'
Making distclean in i18n
/bin/sh: /bework/gnubuild/make-3.79/./make: No such file or directory
make: *** [distclean-recursive] Error 1
$

Apparently $(MAKE) = /bework/gnubuild/make-3.79/./make has been removed
during the "make distclean". I think, recursing into the subdirectories
first, and removing the files in the current directory afterwards should
fix the problem.

Bruno

Re: make-3.79 on BeOS

[Bruno Haible]

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 distclean". I think, recursing into the
>   bh> subdirectories first, and removing the files in the current
>   bh> directory afterwards should fix the problem.
> 
> The ordering of these targets is handled automatically by automake.  I'm
> not aware of any way for automake packages to affect this reliably.
> I'll ask the automake folks what they think.

Alternative solutions would be
- to create the "make" executable under the name "xmake". This is what gcc
  does.
- to create the "make" executable in a subdirectory, say "bin/make".
- to move the entire sources to a src/ subdirectory. This will work, because
  many people have "." in their $PATH, but noone has "src" there.

Bruno

make compilation

[Bruno Haible]

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:

gcc -DALIASPATH=\"/packages/libc6/share/locale:.\" 
-DLOCALEDIR=\"/packages/libc6/share/locale\" -DLIBDIR=\"/packages/libc6/lib\" 
-DINCLUDEDIR=\"/packages/libc6/include\" -DHAVE_CONFIG_H -I. -I. -O2 -g -Wall -c 
job.c
job.c: In function `child_error':
job.c:263: warning: implicit declaration of function `strsignal'
job.c:264: warning: format argument is not a pointer (arg 4)
job.c: In function `start_job_command':
job.c:866: warning: variable `flags' might be clobbered by `longjmp' or `vfork'
job.c:870: warning: variable `argv' might be clobbered by `longjmp' or `vfork'

And the definition of _GNU_SOURCE in "make.h" comes too late, because at
the point where it is defined, a system header file has already been
included ( from "gettext.h"). Fix below. In particular,
"make.h" must always be the first file to be included (also because the
AIX pragma alloca).

Also, in the case where strsignal is not defined by the system, but is defined
in signame.c, wouldn't it be appropriate to #include "signame.h" in job.c?

Bruno

*** make-3.79/expand.c.bak  Thu Feb 24 19:57:23 2000
--- make-3.79/expand.c  Wed May  3 01:57:07 2000
***
*** 17,25 
  the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
  Boston, MA 02111-1307, USA.  */
  
  #include 
  
- #include "make.h"
  #include "filedef.h"
  #include "job.h"
  #include "commands.h"
--- 17,26 
  the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
  Boston, MA 02111-1307, USA.  */
  
+ #include "make.h"
+ 
  #include 
  
  #include "filedef.h"
  #include "job.h"
  #include "commands.h"
*** make-3.79/file.c.bakMon Mar 27 18:20:40 2000
--- make-3.79/file.cWed May  3 01:57:16 2000
***
*** 17,25 
  the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
  Boston, MA 02111-1307, USA.  */
  
  #include 
  
- #include "make.h"
  #include "dep.h"
  #include "filedef.h"
  #include "job.h"
--- 17,26 
  the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
  Boston, MA 02111-1307, USA.  */
  
+ #include "make.h"
+ 
  #include 
  
  #include "dep.h"
  #include "filedef.h"
  #include "job.h"
*** make-3.79/job.c.bak Thu Feb 24 21:26:25 2000
--- make-3.79/job.c Wed May  3 01:57:41 2000
***
*** 17,25 
  the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
  Boston, MA 02111-1307, USA.  */
  
  #include 
  
- #include "make.h"
  #include "job.h"
  #include "debug.h"
  #include "filedef.h"
--- 17,26 
  the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
  Boston, MA 02111-1307, USA.  */
  
+ #include "make.h"
+ 
  #include 
  
  #include "job.h"
  #include "debug.h"
  #include "filedef.h"
*** make-3.79/make.h.bakMon Apr  3 07:45:13 2000
--- make-3.79/make.hWed May  3 02:00:43 2000
***
*** 40,45 
--- 40,50 
  #endif /* C++ or ANSI C.  */
  
  
+ /* Tell the glibc headers that it should declare strsignal().  */
+ /* This must be defined before any system header file is included.  */
+ #define _GNU_SOURCE 1
+ 
+ 
  #include "gettext.h"
  #define _(Text) gettext (Text)
  #define N_(Text)gettext_noop (Text)
***
*** 60,66 
  # define __NO_STRING_INLINES
  #endif
  
- #define _GNU_SOURCE 1
  #include 
  #include 
  #include 
--- 65,70 

make compilation, libit's gettext

[Bruno Haible]

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 does not have it (i.e. on all platforms
without glibc). The default in make-3.79 -- borrowed from libit-0.7 --
is to *always* use the included gettext! Not only does this make the
program larger by 8.5 KB = 6%, it also deprives the user of added
functionality in the glibc-2.2 gettext.

I suggest that the make-3.79 configuration be changed to follow the
behaviour of the AM_GNU_GETTEXT macro.

2) When I try --without-included-gettext, it doesn't even work!! It
leads to link errors:

gcc  -O2 -g -Wall  -o make  ar.o arscan.o commands.o dir.o expand.o file.o function.o 
getopt.o implicit.o job.o main.o misc.o read.o remake.o rule.o signame.o variable.o 
vpath.o default.o remote-stub.o version.o getopt1.o-lutil 
ar.o: In function `ar_name':
/home/bin/make-3.79/ar.c:50: undefined reference to `dcgettext__'
ar.o: In function `ar_touch':
/home/bin/make-3.79/ar.c:173: undefined reference to `dcgettext__'
/home/bin/make-3.79/ar.c:176: undefined reference to `dcgettext__'
/home/bin/make-3.79/ar.c:183: undefined reference to `dcgettext__'
/home/bin/make-3.79/ar.c:190: undefined reference to `dcgettext__'
commands.o:/home/bin/make-3.79/commands.c:483: more undefined references to 
`dcgettext__' follow

I'd now even suggest that you drop libit's gettext, and instead use the
same scheme as textutils, sh-utils, texinfo, lynx, tar, fileutils, gcc, etc.
and which has been working properly for 4 years.

Bruno

Re: make compilation, libit's gettext

[Bruno Haible]

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 checking for an
external variable '_nl_msg_cat_cntr', by compiling

int main ()
{
  extern int _nl_msg_cat_cntr;
  int x = _nl_msg_cat_cntr;
}

Bruno

make-3.79.1 on glibc-2.1.91 (2)

[Bruno Haible]

Hi,

make-3.79.1, built on a recent glibc snapshot, links with the shared
library librt, but doesn't any symbol from this library! Of course this
costs startup time.

The reason is that the function file_timestamp_now() in file.c uses
clock_gettime, but that block depends on

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: Add test evaluating FILE_TIMESTAMP_HI_RES. Define
HAVE_HI_RES_FILE_TIMESTAMP depending on the result. Check for
clock_gettime only if HAVE_HI_RES_FILE_TIMESTAMP is 1.
* filedef.h (FILE_TIMESTAMP_HI_RES): Remove macro.
(FILE_TIMESTAMPS_PER_S, FILE_TIMESTAMP_LO_BITS): Use
HAVE_HI_RES_FILE_TIMESTAMP in place of FILE_TIMESTAMP_HI_RES.
* file.c (file_timestamp_cons): Likewise.
(file_timestamp_now): Likewise.

*** make-3.79.1/configure.in.bakFri Jun 23 18:09:41 2000
--- make-3.79.1/configure.inSat Jul 15 19:31:47 2000
***
*** 53,62 
[make_cv_nsec_timestamps="$enableval"],
[make_cv_nsec_timestamps="yes"])
  
  if test "x$make_cv_nsec_timestamps" != xno; then
AC_STRUCT_ST_MTIM_NSEC
  fi
- jm_AC_TYPE_UINTMAX_T
  
  AC_SUBST(LIBOBJS)
  
--- 53,109 
[make_cv_nsec_timestamps="$enableval"],
[make_cv_nsec_timestamps="yes"])
  
+ jm_AC_TYPE_UINTMAX_T
  if test "x$make_cv_nsec_timestamps" != xno; then
AC_STRUCT_ST_MTIM_NSEC
+   AC_MSG_CHECKING([for high resolution file timestamps])
+   AC_CACHE_VAL(make_cv_hi_res_file_timestamp, [
+ AC_TRY_RUN([
+ #if HAVE_INTTYPES_H
+ # include 
+ #endif
+ #define FILE_TIMESTAMP uintmax_t
+ 
+ #if HAVE_LIMITS_H
+ # include 
+ #endif
+ #ifndef CHAR_BIT
+ # define CHAR_BIT 8
+ #endif
+ #define INTEGER_TYPE_SIGNED(t) ((t) -1 < 0)
+ #define INTEGER_TYPE_MINIMUM(t) \
+   (! INTEGER_TYPE_SIGNED (t) ? (t) 0 : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))
+ #define INTEGER_TYPE_MAXIMUM(t) (~ (t) 0 - INTEGER_TYPE_MINIMUM (t))
+ 
+ #ifdef ST_MTIM_NSEC
+ #define FILE_TIMESTAMP_HI_RES \
+   (2147483647 < INTEGER_TYPE_MAXIMUM (FILE_TIMESTAMP) >> 31)
+ #else
+ #define FILE_TIMESTAMP_HI_RES 0
+ #endif
+ 
+ int main () { exit(FILE_TIMESTAMP_HI_RES ? 0 : 1); }
+ ], make_cv_hi_res_file_timestamp=yes, make_cv_hi_res_file_timestamp=no,
+ make_cv_hi_res_file_timestamp=no)])
+   AC_MSG_RESULT($make_cv_hi_res_file_timestamp)
+   if test $make_cv_hi_res_file_timestamp = yes; then
+ val=1
+   else
+ val=0
+   fi
+   AC_DEFINE_UNQUOTED(HAVE_HI_RES_FILE_TIMESTAMP, $val,
+  [Define if files can have high resolution timestamps.])
+ 
+   if test $make_cv_hi_res_file_timestamp = yes; then
+ # Solaris 2.5.1 needs -lposix4 to get the clock_gettime function.
+ # Solaris 7 prefers the library name -lrt to the obsolescent name -lposix4.
+ AC_SEARCH_LIBS(clock_gettime, [rt posix4])
+ if test "$ac_cv_search_clock_gettime" != no; then
+   AC_DEFINE(HAVE_CLOCK_GETTIME, 1,
+ [Define if you have the clock_gettime function.])
+ fi
+   fi
  fi
  
  AC_SUBST(LIBOBJS)
  
***
*** 73,86 
  fi
  AC_MSG_RESULT($ac_cv_check_symbol_$1)])dnl
  
- # Solaris 2.5.1 needs -lposix4 to get the clock_gettime function.
- # Solaris 7 prefers the library name -lrt to the obsolescent name -lposix4.
- AC_SEARCH_LIBS(clock_gettime, [rt posix4])
- if test "$ac_cv_search_clock_gettime" != no; then
-   AC_DEFINE(HAVE_CLOCK_GETTIME, 1,
- [Define if you have the clock_gettime function.])
- fi
- 
  # See if we have a standard version of gettimeofday().  Since actual
  # implementations can differ, just make sure we have the most common
  # one.
--- 120,125 
*** make-3.79.1/filedef.h.bak   Tue Jun 20 16:00:16 2000
--- make-3.79.1/filedef.h   Sat Jul 15 19:34:36 2000
***
*** 110,122 
  extern void notice_finished_file PARAMS ((struct file *file));
  
  
! #ifdef ST_MTIM_NSEC
! # define FILE_TIMESTAMP_HI_RES \
! (2147483647 < INTEGER_TYPE_MAXIMUM (FILE_TIMESTAMP) >> 31)
  # define FILE_TIMESTAMP_STAT_MODTIME(fname, st) \
  file_timestamp_cons (fname, (st).st_mtime, (st).st_mtim.ST_MTIM_NSEC)
  #else
- # define FILE_TIMESTAMP_HI_RES 0
  # define FILE_TIMESTAMP_STAT_MODTIME(fname, st) \
  file_timestamp_cons (fname, (st).st_mtime, 0)
  #endif
--- 110,119 
  extern void notice_finished_file PARAMS ((struct file *file));
  
  
! #if HAVE_HI_RES_FILE_TIMESTAMP
  # define FILE_TIMESTAMP_STAT_MODTIME(fname, st) \
  file_timestamp_cons (fname, (st).st_mtime, (st).st_mtim.ST_MTIM_NSEC)
  #else
  # define FILE_TIMESTAMP_STAT_MODTIME(fname, st) \
  file_timestamp_cons (fname, (st).st_mtime, 0)
  #endif
***
*** 126,133

make-3.79.1 on glibc-2.1.91

[Bruno Haible]

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 also has an
(unrelated) libutil. This code from AC_FUNC_GETLOADAVG

# Check for the 4.4BSD definition of getloadavg.
AC_CHECK_LIB(util, getloadavg,
  [LIBS="-lutil $LIBS" ac_have_func=yes ac_cv_func_getloadavg_setgid=yes])

ought to be changed to

# Check for the glibc-2.2 definition of getloadavg.
AC_CHECK_FUNC(getloadavg, [ac_have_func=yes])
# Check for the 4.4BSD definition of getloadavg.
if test $ac_have_func = no; then
  AC_CHECK_LIB(util, getloadavg,
[LIBS="-lutil $LIBS" ac_have_func=yes ac_cv_func_getloadavg_setgid=yes])
fi

This way, getloadavg is recognized as existent, but -lutil is not
unnecessarily added to LIBS.

Bruno

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

[Bruno Haible]

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. Therefore compiling the make-3.79.1 code
without optimization but without -lutil will result in a link error.
Since looking into the optimization flags in order to know whether to
link in libutil.so is too tricky, it is preferrable to determine a
priori whether libutil.so will be needed.

Bruno

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

[Bruno Haible]

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

[Bruno Haible]

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
$ ../configure
$ make
- make a distribution package:
$ make dist

You will observe that the created distribution contains a tests/msguniq-1.out
file which differs from the one in the source. During the "make dist" a
dependency of 'distdir' on 'msguniq-1.out' has caused the following command
to be executed:
cp ../../tests/msguniq-1 msguniq-1.out

Both 'msguniq-1' and 'msguniq-1.out' exist in the source directory ../../tests,
and 'msguniq-1.out' is older than 'msguniq-1'. This has apparently triggered
the implicit rule.

I'd like to ask to remove this misfeature rule from GNU make because

  1) It is undocumented. The "make" documentation (node "Catalogue of Implicit
 Rules") doesn't mention this pattern rule. It only mentions the .out
 suffix, but the tests/Makefile redefines the suffix list anyway.

  2) It cannot be turned off in a portable way. Node "Canceling Implicit Rules"
 recommends redefining the same pattern rule with no commands. But
 since pattern rules are not portable (see SUSV2 "make" documentation),
 I cannot do that in a portable Makefile.

  3) Compared to the rationale of the rule, namely the ability to write
 rules like

.out.symlist :
nm $< > $@

 which create 'foo,symlist' from 'foo', its implementation is gross:
 it copies the complete executable file. This is a case where pattern
 rules are needed.

Bruno

___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

incorrect error message

[Bruno Haible]

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 foo.erg
make: *** No rule to make target `foo.erg'.  Stop.
$ make foo.erw
make: *** No rule to make target `../baz', needed by `foo.erw'.  Stop.
$ make foo.res
make: *** No rule to make target `../baz', needed by `foo.res'.  Stop.

The first error message is incorrect and should look like the other two:
make: *** No rule to make target `../bar', needed by `foo.erg'.  Stop.

Bruno



___
Bug-make mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-make

"make -jN" requires mechanical changes to a Makefile

[Bruno Haible]

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 make these
changes?

Namely, consider this Makefile:
===
all : copy1 copy2 copy3 copy4

copy1 copy2 copy3 copy4: 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
===

Observe:
* "rm -f copy?; make" works fine.
* "rm -f copy?; make -j8" occasionally fails:
$ rm -f copy? ; make -j8
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy2
install: cannot change permissions of 'copy2': No such file or directory
install -c -m 644 Makefile copy3
Makefile:4: recipe for target 'copy2' failed
make: *** [copy2] Error 1
make: *** Waiting for unfinished jobs
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4
install -c -m 644 Makefile copy4
install -c -m 644 Makefile copy4

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
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4
===

This is tedious, mechanical work. Couldn't GNU make implement the workaround
by itself? Namely, when during a parallel make, it encounters a rule

target1 ... targetN : dependencies
STATEMENTS

and none of the statements depends on the precise target ($@ or similar),
it should transform that to the form

target1 ... targetN : intermediate_target
.PHONY: intermediate_target
intermediate_target: dependencies
STATEMENTS

internally.

$ make --version
GNU Make 4.1

Best regards,

  Bruno

[1] https://www.gnu.org/prep/standards/html_node/Makefile-Basics.html


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Bruno Haible]

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
>   copy4: Makefile
>   install -c -m 644 Makefile copy4

The Makefile was simplified. In the real-world case [1], the STATEMENTS
is a recursive invocation of another Makefile, which is generated by
Automake, and for which I cannot create a separate targets
  install-textstyle.h
  install-textstyle_stdbool.h
  install-textstyle_version.h
  install-textstyle_woe32dll.h
(because Automake just does not offer this).

Another real-world example (where a parallel make problem surely
exists, but wasn't reported so far) is this rule from
gettext/gettext-tools/src/Makefile.am:

po-gram-gen.c po-gram-gen.h: po-gram-gen.y
$(AM_V_GEN)$(SHELL) $(YLWRAP) $(srcdir)/po-gram-gen.y \
  y.tab.c po-gram-gen.c \
  y.tab.h po-gram-gen.h \
  y.output po-gram-gen.output \
  -- $(YACC) $(YFLAGS) $(AM_YFLAGS) \
&& sed -e 's|".*/po-gram-gen.y"|"po-gram-gen.y"|' < po-gram-gen.c > 
po-gram-gen.c-tmp \
&& rm -f po-gram-gen.c \
&& mv po-gram-gen.c-tmp $(srcdir)/po-gram-gen.c \
&& { test '$(srcdir)' = . || mv po-gram-gen.h $(srcdir)/po-gram-gen.h; }

It's the same type of problem, and the same mechanical change is needed
for proper support of parallel make.

> I really don't like to try to parse recipes and modify
> behavior depending on what is found.  It leads to a lot of unexpected
> consequences and confusion.

In the current state, supporting parallel make requires extra work
for the maintainer.

Or would you recommend that I add this snippet to the top-level
Makefile of all my projects?

# This package does not support parallel make.
# So, turn off parallel execution (at least in GNU make >= 4.0).
GNUMAKEFLAGS = -j1

Bruno

[1] https://lists.gnu.org/archive/html/bug-gettext/2019-05/msg00084.html


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Bruno Haible]

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 compromise, when only few Makefiles
have problems with parallel make.

Whereas the snippet I showed turns it off for an entire package (when placed
in the top-level Makefile).

Thanks for the suggestion.

Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Bruno Haible]

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
>   install -c -m 644 Makefile copy2
>   install -c -m 644 Makefile copy3
>   install -c -m 644 Makefile copy4
> ===

This workaround doesn't actually work (in the actual case of GNU gettext):
it fails the "make distcheck" verification.

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 copy3
install -c -m 644 Makefile copy4
copy2 copy3 copy4: copy1
===

Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Bruno Haible]

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 copy3
> > install -c -m 644 Makefile copy4
> > copy2 copy3 copy4: copy1
> > ===
> 
> This is not fully-correct either:
> 
>   $ make
>   install -c -m 644 Makefile copy1
>   install -c -m 644 Makefile copy2
>   install -c -m 644 Makefile copy3
>   install -c -m 644 Makefile copy4
> 
>   $ rm copy3
> 
>   $ make
>   make: Nothing to be done for 'all'.

Indeed. Thank you for having spotted this; otherwise I would have put a
broken rule into GNU gettext.

Now, when my use-case is:
  - one rule that produces N files (N > 1),
  - I want "make" to execute the rule only once, not N times,
even with parallel make.
What is the solution? The documentation page [1] explicitly does NOT mention
this use-case for multiple targets on the same rule.

You mentioned splitting the rule into one rule per file. But bison does not
work this way; it really produces two files at once. And for other rules
I mentioned Automake limitations.

Parallel make is of growing importance, because Debian now uses parallel builds
by default (quote: "debhelper >= 10 defaults to parallel build").

Bruno

[1] https://www.gnu.org/software/make/manual/html_node/Multiple-Targets.html


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Bruno Haible]

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 "representative" file should be copy4 here, because it's the one
that gets created last.

Otherwise, when the user interrupts "make" after copy1 was created but before
copy2, copy3, copy4 are created, and then retries "make" again, the second
'make' invocation will fail somewhere when it references copy2...copy4.

Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Bruno Haible]

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
> > 
> > I think the "representative" file should be copy4 here, because it's the one
> > that gets created last.
> 
> That sort of thing is only true in serial make, you can't rely on it in 
> parallel make.

The sequence of lines of the recipe of a rule gets executed in order,
even in parallel make, no?

Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

make-4.3: wildcard test #9 fails

[Bruno Haible]

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

1 Test in 1 Category Failed (See .diff* files in work dir for details) :-(

Makefile:1998: die Regel für Ziel „check-regression“ scheiterte
make[2]: *** [check-regression] Fehler 1

$ cat tests/work/functions/wildcard.diff.9
*** work/functions/wildcard.base.9  Sun Apr  5 15:16:18 2020
--- work/functions/wildcard.log.9   Sun Apr  5 15:16:18 2020
***
*** 1 
! __ldir
--- 1 
! 

This is on an ext4 file system.
It's not locale dependent: the same result occurs with 'LC_ALL=C make check'.

Additional data:

$ nm make | grep wildcard
0040f820 t func_wildcard
$ nm make | grep glob
00408620 T ar_glob
00408280 t ar_glob_match
0040b220 T dir_setup_glob
00408210 t __do_global_dtors_aux
00632e08 t __do_global_dtors_aux_fini_array_entry
00634560 b global_dl.6802
006341d0 d global_setlist
00637080 b global_variable_set
 U globfree@@GLIBC_2.2.5
 U glob@@GLIBC_2.2.5
00424760 T init_hash_global_variable_set

Bruno

Re: make-4.3: wildcard test #9 fails

[Bruno Haible]

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 glob.c from 1999 :-(

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/glob.html

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

[Bruno Haible]

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 Makefile. For simplicity, here, use a rule that
creates 4 files copy1, copy2, copy3, copy4.

===
all : copy1 copy2 copy3 copy4

copy1 copy2 copy3 copy4: 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
===

Unfortunately, with "make -j8", it invokes the rule multiple times.

It is possible to change this Makefile so that
  (A) "rm -f copy?; make" executes the rule once.
  (B) "rm -f copy?; make -j8" executes the rule once as well.
  (C) After "make", another "make" just prints "Nothing to be done for 'all'."
  (D) After removing one of the files copy?, "make" executes the rule once.
  (This covers also the case of pressing Ctrl-C during "make", then
  doing "make" again.)
  (E) After replacing one of the files copy? with a file that is older than
  Makefile, "make" executes the rule once.

There are three possibilities:


(I) Assuming GNU make >= 4.3, the "Grouped explicit target" syntax does it.
Thanks to Kaz Kylheku and Paul Smith for having added this.

===
all : copy1 copy2 copy3 copy4

copy1 copy2 copy3 copy4 &: 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
===

But it will take a number of years until we can assume that all 'make'
programs that we care about support this syntax.


(II) It is possible to turn off parallel make. This does it:

===
all : copy1 copy2 copy3 copy4

copy1 copy2 copy3 copy4 : 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

# This Makefile contains rules which don't work with parallel make.
# So, turn off parallel execution in this Makefile.
.NOTPARALLEL:
===

But some people who want to minimize wall-clock execution time of
their builds may not like it.


(III) Use portable make syntax and still allow parallel make.

This is a bit harder. My solution is to first analyze in which order
the rule will generate the various files and thus what the expected
timestamp order is. In this case, it is:
  Makefile <= copy1 <= copy2 <= copy3 <= copy4

First some attempts that don't work:

===
all : copy1 copy2 copy3 copy4

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

copy2 copy3 copy4: copy1
===

Fails (E).

===
all : copy1 copy2 copy3 copy4

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

copy1 copy2 copy3: copy4
===

Fails (E) as well.

===
all : copy1 copy2 copy3 copy4

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

copy1: copy4
test -f copy1 || { rm -f copy4; $(MAKE) copy4; }
copy2: copy4
test -f copy2 || { rm -f copy4; $(MAKE) copy4; }
copy3: copy4
test -f copy3 || { rm -f copy4; $(MAKE) copy4; }
===

Fails (E) for copy1, ..., copy3.
And fails (C), i.e. clutters the "make" output.

===
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; }
copy3: copy2
{ test -f copy3 && test ! copy3 -ot copy2; } || { rm -f copy4; $(MAKE) 
copies; }
copy4: copy3
{ test -f copy4 && test ! copy4 -ot copy3; } || { rm -f copy4; $(MAKE) 
copies; }

copies:
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4
.PHONY: copies
===

This solution fulfils all the requirements.

Can we use 'test FILE1 -ot FILE2'?
- POSIX 'test' does not support this option.
 

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

[Bruno Haible]

> ===
> 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; }
> copy3: copy2
>   { test -f copy3 && test ! copy3 -ot copy2; } || { rm -f copy4; $(MAKE) 
> copies; }
> copy4: copy3
>   { test -f copy4 && test ! copy4 -ot copy3; } || { rm -f copy4; $(MAKE) 
> copies; }
> 
> copies:
>   install -c -m 644 Makefile copy1
>   install -c -m 644 Makefile copy2
>   install -c -m 644 Makefile copy3
>   install -c -m 644 Makefile copy4
> .PHONY: copies
> ===
> 
> This solution fulfils all the requirements.

It can be simplified a bit. And remove verbosity:

===
all : copy1 copy2 copy3 copy4

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

copies:
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4
.PHONY: copies
===

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

[Bruno Haible]

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 invocation, then your
> best bet is to modify this rule into two rules:
> 
> ... : .sentinel ;
> 
>   .sentinel: 
>   
>   @touch $@
> 
> Note, it's critical to include the semicolon here.  Or if you prefer to
> be more explicit you can write something like:
> 
> ... : .sentinel
>   : do nothing
> 
> This will work properly.

Thanks for showing this idiom.

I think this can be improved a bit: Instead of 'touch .sentinel' I would
use 'echo > .sentinel'. Because if you use 'touch .sentinel' and the build
directory is on an NFS mount and the clock of the NFS server is ahead the
clock of localhost (I have seen this quite frequently), the timestamp of
.sentinel will be behind the timestamp of the newest , and thus
another "make" run will execute the rule again.

Still, I don't like these '.sentinel' or stamp files, because they
add complexity:
  * The developer has to decide whether the stamp file should go into
the build dir or $(srcdir). The general rule should be that if
 uses only build tools that are guaranteed to be present,
then   ... and the stamp file should go into the build dir,
whereas if they use less common tools (e.g. bison), they should
all go into $(srcdir).
  * The automake dist target needs to be adjusted to include this stamp
file.
  * Version control (.gitignore) needs to be adjusted to include this
stamp file.

I'll use the rule with a phony target and 'test ... -ot ...', unless you
find a problem with it (other than the potential portability problem
redarding 'test').

Bruno

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

[Bruno Haible]

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 644 Makefile copy4
> ===

Fails (D) and (E). => Not a solution to the problem.

Bruno

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

[Bruno Haible]

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 enough room.
  2) It creates one more directory that requires either regular attention
 (so that it does not fill up over time) or a fascist policy of the
 kind "let's remove the contents of this directory regularly".

Suggestion: Use ${TMPDIR-/tmp} instead.

See also [1].

Bruno

[1] 
https://superuser.com/questions/332610/where-is-the-temporary-directory-in-linux

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

[Bruno Haible]

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 -> private/etc
> lrwxr-xr-x@ 1 root  wheel  11 Feb 10  2015 /tmp -> private/tmp

/tmp is world-writable, of course:

$ ls -lLd /etc /tmp
drwxr-xr-x@ 124 root  wheel  3968 27 Jun 01:25 /etc
drwxrwxrwt@   8 root  wheel   256 18 Jul 14:38 /tmp

Bruno

GNU make 4.3.91 on Debian 9.1

[Bruno Haible]

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

[Bruno Haible]

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

[Bruno Haible]

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


centos8s-clang-failures.tar.gz
Description: application/compressed-tar

GNU make 4.3.91 on Manjaro 17

[Bruno Haible]

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

[Bruno Haible]

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 
-L/home/bruno/prefix32/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  -lguile-2.2 -lgc  
lib/libgnu.a   -ldl 
/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../libguile-2.2.so when searching 
for -lguile-2.2
/bin/ld: skipping incompatible /usr/lib/libguile-2.2.so when searching for 
-lguile-2.2
/bin/ld: cannot find -lguile-2.2
/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../libgc.so when searching for -lgc
/bin/ld: skipping incompatible /usr/lib/libgc.so when searching for -lgc
/bin/ld: cannot find -lgc
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:821: make] Error 1

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.

The configuration has produced incorrect results:
...
checking for GNU Guile... 2.2
checking for GUILE... yes
checking for libguile.h... yes
...
The first two among these findings are wrong, since /usr/lib32/libguile.* does
not exist.

$ grep GUILE config.status
S["HAVE_GUILE_FALSE"]="#"
S["HAVE_GUILE_TRUE"]=""
S["GUILE_LIBS"]="-lguile-2.2 -lgc "
S["GUILE_CFLAGS"]="-I/usr/include/guile/2.2 -pthread "
D["HAVE_GUILE"]=" 1"

These five values are all wrong.

Bruno

GNU make 4.3.91 on openSUSE Leap 15.2

[Bruno Haible]

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

[Bruno Haible]

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

[Bruno Haible]

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-bit mode, the compilation works fine, but there
are 20 test failures. In 32-bit mode, even 24 test failures.



solaris114-failures.tar.gz
Description: application/compressed-tar


omnios-failures.tar.gz
Description: application/compressed-tar


openindiana-failures.tar.gz
Description: application/compressed-tar

GNU make 4.3.91 on Cygwin

[Bruno Haible]

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

[Bruno Haible]

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

[Bruno Haible]

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/bruno/include -Wall  -g -O2 -MT 
src/arscan.o -MD -MP -MF $depbase.Tpo -c -o src/arscan.o ../src/arscan.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from ../src/makeint.h:151,
 from ../src/arscan.c:17:
../src/arscan.c: In function 'ar_scan':
../src/arscan.c:729:60: error: 'PATH_MAX' undeclared (first use in this 
function); did you mean 'PATH_VAR'?
  729 |   if (err || name_len == 0 || name_len >= MIN (PATH_MAX, 
INT_MAX))
  |^~~~
../src/arscan.c:729:60: note: each undeclared identifier is reported only once 
for each function it appears in
make[1]: *** [Makefile:885: src/arscan.o] Error 1

PATH_MAX does not exist on GNU/Hurd (intentionally, because file names are
of arbitrary length).

Bruno

GNU make 4.3.91 on other platforms

[Bruno Haible]

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

[Bruno Haible]

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

If the test hit a timeout, the timeout is definitely too small.

> On that occasion the machine was heavily
> loaded, so i thought make did not have a chance to run in that time
> frame.  In your case was the test running on some loaded machine or a
> poor virtual machine?

It's in a VM, but in a fast one, due to good hardware. In the VM, I had
only "make check" running. The load of the entire system was about 2.5
when I had 6 VMs open simultaneously, on a CPU with 8 cores.
All VMs configured to use nested paging, and so on.
In the 'make-4.3.91' directory:
  time ./configure  7.4 sec
  time make 5.6 sec

Bruno

Re: GNU make 4.3.91 on Debian 9.1

[Bruno Haible]

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

Some testers (like Nelson Beebe) have more evolved "platform testing scripts"
than others. I use some "platform testing routine", that involves looking at
the "make check" output and guess what info would be useful to send back.

> With an error I'd like to get various other files such as the
> src/config.h file, the config.status file if it exists, plus the
> test/work directory and also the output of the configure/build/test
> run.

It would be useful to formalize this, so that the platform testers' feedback
becomes more useful to you. For example, Nelson's summary today [1] shows
that he thought it would be useful to report the part of the "make check"
output that contains the failures. I thought — seeing the line
  3 Tests in 3 Categories Failed (See .diff* files in work dir for details)
— that it would be good to do
cd tests; tar cvfz $platform-failures.tar.gz `find work -name '*.diff*'`
and send that. It turns out that both are insufficient for your analysis.
If you tell us what to return as part of the feedback, we can accommodate it.

Many GNU packages create a 'test-suite.log' file, that contains the list of
failed or skipped tests, plus the log file (stdout+stderr) for each. This
makes it simple: As a tester, I simply attach this test-suite.log (or the
parts I judge relevant).

> the config.status file if it exists

Yes, the config.status file is useful to attach, especially when the
compilation failed, but probably also when the compilation succeeded and
some tests failed.

> the src/config.h file

The src/config.h is redundant IMO, since it is derived from config.status.

> plus the test/work directory

All of it? Or a selected part of it?

> and also the output of the configure/build/test run.

Nelson and I do keep these outputs, as part of our build scripts. If you
want it, we can send it. We only need to know what to send.

> I'm happy to add something to GNU make to collect "useful stuff" if
> there's a standard way that testers would like it.
> 
> Maybe just augmenting the check target to do more?

Yes. Instead of printing
  See .diff* files in work dir for details
it could
  - generate a summary file with details (like test-suite.log, described
above), and/or
  - generate tarball with useful info to send, and/or
  - (if you prefer receiving mails with several attachments instead of a
tarball attachment) print a list of files to send.
And ideally, also print the email address for the reports. I sent my reports
to bug-make@; Nelson sent his to platform-testers@.

Assuming what you want is a tarball with
  config.status
  `find tests/work -name '*.diff*'`
  `find tests/work -name '*.diff*' | sed -e 's/\.diff/.log/'`
that's what I'm sending now.

Bruno

[1] https://lists.gnu.org/archive/html/platform-testers/2022-10/msg5.html


debian91-failures.tar.gz
Description: application/compressed-tar

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

[Bruno Haible]

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 test failure, that is, to
exhibit the new behaviour of $(wildcard) even on older glibc systems. The way
to do so would be to use the Gnulib module 'glob', which is documented to fix
this problem: https://www.gnu.org/software/gnulib/manual/html_node/glob.html

Currently GNU make uses only part of the Gnulib module 'glob': It has the .c
file, but uses a module 'make-glob' instead of 'glob'. On Debian 9.1, this
module produces:
- during configuration the message "checking if system libc has GNU glob...
yes"
- in config.status the substitution USE_SYSTEM_GLOB ← yes.

That's why we see this test fail on glibc < 2.27 (and likely also AIX 7.2,
Solaris 11.4) systems.

But it's not all so simple to use full Gnulib modules in GNU make, see
gl/README...


___

Reply to this item at:

  

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

Re: GNU make 4.3.91 on Cygwin

[Bruno Haible]

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 failures
  work/features/exec.diff
  work/options/dash-l.diff

> I'd just like to make sure I didn't
> make things significantly worse there.

In 4.3.91 I saw 11 failures:
  work/features/exec.diff
  work/features/jobserver.diff
  work/features/jobserver.diff.1
  work/features/jobserver.diff.11
  work/features/jobserver.diff.2
  work/features/jobserver.diff.6
  work/features/parallelism.diff.12
  work/features/parallelism.diff.4
  work/features/recursion.diff
  work/functions/shell.diff.20
  work/misc/general4.diff.9

> I could remove the
> MinGW shutils from my PATH and get the suite working without them but I
> don't want to undertake that for this release.

For the Cygwin port, this wouldn't help.

For the mingw port, it sounds like Eli already has some patches (or at least
he knows which places need to be patched) [1].

Bruno

[1] https://lists.gnu.org/archive/html/bug-make/2022-10/msg00168.html


cygwin-make4.3-failures.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.91 on CentOS 8 Stream

[Bruno Haible]

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

[Bruno Haible]

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
>   make: *** [Makefile:1192: distcheck] Error 1
> 
> The tar file is named with the host triplet, and all the things I might
> want (hopefully!!) are there.  It exists in the working directory.

Thank you! That should make the next reports by Nelson and me much more useful
to you.

Bruno

Re: GNU make 4.3.92 on Debian 9.1

[Bruno Haible]

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 .. FAILED (9/10 passed)



makeerror-i686-pc-linux-gnu-debian9.1.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Debian 11.1

[Bruno Haible]

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

[Bruno Haible]

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

Re: GNU make 4.3.92 on Manjaro 17

[Bruno Haible]

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

[Bruno Haible]

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 can find the header we're good to go.

Unfortunately, it did not fix the problem. Find attached the details
of that failed build.



makeerror-manjaro17-32bit.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on openSUSE Leap 15.2

[Bruno Haible]

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: application/compressed-tar

Re: GNU make 4.3.92 on FreeBSD

[Bruno Haible]

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

[Bruno Haible]

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 Solaris 11 OpenIndiana, in 64-bit mode, the compilation works fine, but 
> there
> are 20 test failures. In 32-bit mode, even 24 test failures.

With GNU make 4.3.92, the results are much better:
  - On Solaris 11.4 and Solaris 11 OpenIndiana, all tests pass.
  - On Solaris 11 OmniOS, there are only 3 test failures. Attached.



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

Re: GNU make 4.3.92 on GNU/Hurd

[Bruno Haible]

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

Thanks. With GNU make 4.3.92, the compilation now succeeds, but there are
9 test failures.



makeerror-i686-unknown-hurd.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on mingw

[Bruno Haible]

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

[Bruno Haible]

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

[Bruno Haible]

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

[Bruno Haible]

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 file descriptor which was meant to be left open in 1 process
only is actually open in 2 or more processes.

> Can you please tell us how to reproduce (either sun or centos)? Where
> do you get your vm image, how you run it, any specific env settings,
> which compiler, any other important details?

Sure.

=== CentOS 8 stream installation =

Use CentOS 8 stream 2022-10-05 from
https://ftp.gwdg.de/pub/linux/centos/8-stream/isos/x86_64/

RAM size: 1.0 GiB
CPUs: 1
Disk size: 15 GB.

The installation menu is in a stupid order: Can only enable NTP servers
after networking is enabled! Therefore do things in this order:

Installation Destination:
Storage Configuration: Custom
Standard Partition  14 GiB (14336 MiB)  /  ext4
Standard Partition  1  GiB (1024 MiB)   swap

KDump:
Disable kdump.

Network & host name:
Enable networking.
Ethernet config: General > Enable "Connect automatically".
Host name: centos8s

Time & Date:
Set time zone.
Disable then Enable "Network Time".

Installation Source:
On the network, https://ftp.gwdg.de/pub/linux/centos/8-stream/BaseOS/x86_64/os/
URL type: repository URL
Deselect AppStream.
Select AppStream.

Software selection:
  Base Environment: Workstation
  Add-ons: Development Tools, Graphical Administration Tools

Root password:
  login: root
  password: **
  Press "Done" twice.

User settings:
  login: bruno
  password: **
  Select "Make this user administrator".
  Press "Done".

Click "Begin installation".

Wait for the installation to complete.

Power off. Eject CD.

Welcome wizard:
  Privacy: Location services: off.

Popup menu > Settings > Privacy > Screen Lock
Automatic screen lock = Off

Popup menu > Settings > Power > Power Saving
Blank screen = Never

Activities > Software > Updates: Refresh. -> Up to date.

Activities > Software

Search: GNU Emacs, install
Search: gVim, install

$ dnf list
# Not needed:
#$ sudo dnf install make
#$ sudo dnf install gcc
#$ sudo dnf install gcc-c++

Power Off.

=== CentOS 8 stream build configuration ==

CC="gcc"; CXX="g++"; export CC CXX

../configure --prefix=$HOME/inst-x86_64-64 \
 CPPFLAGS="-I$HOME/inst-x86_64-64/include -Wall" \
 LDFLAGS="-L$HOME/inst-x86_64-64/lib" 2>&1 | tee log1 \
&& make 2>&1 | tee log2 \
&& make check 2>&1 | tee log3

=== Solaris 11 OmniOS installation =

OmniOS, a distro based on Illumos - roughly Solaris 11 compatible.

Download OmniOS release 2020-11-02 from
https://downloads.omniosce.org/media/stable/omniosce-r151036.iso

RAM size: 1.5 GiB
CPUs: 1
Disk size: 10 GB

Host name: omnios
Time zone: Europe / Germany / Germany
Configure:
  Networking:
Configuration mode: DHCP
  User:
Login: bruno
Password: **
Grant both administrator and sudo role
  Root password: **
Reboot

Eject CD/DVD. Reboot.

https://omniosce.org/info/getstarted.html

# pkg refresh
# pkg list -u
# pkg update
# pkg install pkg:/package/pkg
# pkg update

Reboot.

Package repositories:
https://omniosce.org/info/ipsrepos.html
-> https://pkg.omniosce.org/r151036/core/en/catalog.shtml
-> https://pkg.omniosce.org/r151036/extra/en/catalog.shtml

# pkg search /usr/bin/gcc
# pkg search /usr/bin/g++
# pkg search /usr/include/stdio.h
# pkg search /usr/bin/gdb   # none, use mdb instead
# pkg search /usr/bin/emacs # none, use vi = vim instead

# pkg install /developer/gcc9
# pkg install /system/header
# pkg install /developer/build/gnu-make

=== Solaris 11 OmniOS build configuration =

CC="gcc -O2"; CXX="g++ -O2"; export CC CXX
CONFIG_SHELL=/usr/bin/bash; export CONFIG_SHELL

../configure --prefix=$HOME/prefix64 \
 CPPFLAGS="-I$HOME/prefix64/include -Wall" \
 LDFLAGS="-L$HOME/prefix64/lib" 2>&1 | tee log1 \
&& gmake 2>&1 | tee log2 \
&& gmake check 2>&1 | tee log3

=

GNU make 4.4 on Solaris OpenIndiana

[Bruno Haible]

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

Bruno


makeerror-4.4-x86_64-pc-solaris2.11-qha4.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on CentOS Stream

[Bruno Haible]

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-make/2022-10/msg00125.html .


makeerror-4.4.0.90-x86_64-pc-linux-gnu-itaa.tar.gz
Description: application/compressed-tar


makeerror-4.4.0.90-x86_64-pc-linux-gnu-dzg1.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on Debian 11.1

[Bruno Haible]

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

Re: GNU Make 4.4.0.90 on Debian 9.1

[Bruno Haible]

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 failures reported at that time are
  gone (already gone in
  https://lists.gnu.org/archive/html/bug-make/2022-10/msg00208.html ).

- There are 4 new failures in the 'features/archives' category. Looks
  similar to those just reported in
  https://lists.gnu.org/archive/html/bug-make/2023-01/msg00098.html .



makeerror-4.4.0.90-i686-pc-linux-gnu-ryj5.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on openSUSE Leap 15.2

[Bruno Haible]

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 failures reported at that time are
  gone.

- There are 4 new failures in the 'features/archives' category. Looks
  similar to those just reported in
  https://lists.gnu.org/archive/html/bug-make/2023-01/msg00098.html .



makeerror-4.4.0.90-x86_64-pc-linux-gnu-bgji.tar.gz
Description: application/compressed-tar

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

[Bruno Haible]

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/compressed-tar

Re: GNU Make 4.4.0.90 on Debian 11.1

[Bruno Haible]

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 'gcc' in $PATH on this system. The reason is
that several C compilers can be chosen. I installed GCC 10, and then set the
environment variable
  CC="gcc-10"
and this is found in $PATH, as /usr/bin/gcc-10.

Per GNU standards [1], a GNU package should use $CC, not 'cc' — so that users
have the freedom to use a compiler of their choice (clang, TinyCC, whatever...).

In this test you have the lines

  # Fallback if configure did not find AR
  my $ar = get_config('AR') || 'ar';

Why not do the same for CC?

  my $cc = get_config('CC') || 'cc';

Bruno

[1] https://www.gnu.org/prep/standards/html_node/Configuration.html

Re: GNU Make 4.4.0.90 on GNU/Hurd

[Bruno Haible]

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'



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

Re: GNU Make 4.4.0.90 on macOS 12

[Bruno Haible]

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

[Bruno Haible]

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.

 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Download 
https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/20220824/debian-sid-hurd-i386-DVD-1.iso

Start VirtualBox. Create new VM.

Disk size: 8 GB

Pseudo-graphical install.
Language: English
Location: United States
Keymap: American English
Hostname: **
Domain name: **

No root account.
login: **
password: **

Accept a dummy time zone.

Partitioning: Entire disk. All files in one partition.

Software selection: Debian desktop environment. (Well, that was not necessary,
as I didn't really get the desktop running later.)

Reboot. Eject CD-ROM.

Set time zone: sudo dpkg-reconfigure tzdata

Install packages:
Insert CD-ROM, boot, "Boot from first hard disk".
$ sudo apt install g++-12 gdb make vim
$ sudo apt install emacs # not available

Package list for further packages:
https://packages.debian.org/en/sid/

Re: GNU/Hurd installation

[Bruno Haible]

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
>   module 1: ext2fs ...
>   module 2: exec $(exec-task=task-create)
>   3 multiboot modules
>   task loaded: ext2fs ...
>   zip:device:rd0
>   task loaded: exec
> 
>   start ext2fs: _
> 
> and hangs there.

In my instructions for GNU/Hurd in 2020 I had noted
  Disable 'Nested paging', otherwise it DOES NOT BOOT!

So, maybe it's worth looking at the main parameters of the VirtualBox VM:
  - General: Operating System: Other/Unknown
  - System: Motherboard: *Disable* all extended features (I/O APIC, EFI)
  - System: Processor: *Disable* all extended features (PAE/NX, Nested VT-x)
[The latter is what I meant above.]
  - System: Paravirtualization Interface: You can try different values
than 'Default'.

Do you have other VirtualBox VMs that work? If not, i.e. if you get problems
also with other OSes as guests, I would verify that VT-x/AMD-V is enabled in
the UEFI/BIOS.

Bruno

Re: GNU/Hurd installation

[Bruno Haible]

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, this magic pixie dust depends on your CPU model, UEFI/BIOS
settings, Linux host kernel version, and VirtualBox version. I've had VMs
that became unbootable after moving to a newer hardware, and vice versa.
The VirtualBox documentation [1] gives a certain amount of background
knowledge, which is then the basis for finding the right setting that
makes things work.

Sorry, I had expected that it would be as smooth for you as it was for me.

Bruno

[1] https://www.virtualbox.org/manual/UserManual.html

Re: GNU Make 4.4.0.90 on Solaris 11.4

[Bruno Haible]

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

[Bruno Haible]

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 build: makeerror-4.4.0.90-x86_64-pc-solaris2.11-hhav.tar.gz

These 3 failures were already seen at
.


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


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

Re: GNU Make 4.4.0.90 on Solaris 11 OpenIndiana

[Bruno Haible]

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 with
OmniOS) and why only in 64-bit mode.

Find attached the logs.


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

Re: GNU Make 4.4.0.90 on AIX 7.2

[Bruno Haible]

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 category 'features/archives'.
  Error message:
/home/haible/make-4.4.0.90/build-64-xlc/tests/../make: invalid option -- X
Usage: make [options] [target] ...
Options:
...
  Apparently the value of ${AR} or the value of ${NM} is being decomposed, and
  the -X option, meant for the 'ar' or the 'nm' program, is being passed to
  'make'.

* 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 seen this many years ago, in AIX 4 or AIX 5.)

* 3 failures in category 'features/output-sync'.
  Error message is "timeout after 10 seconds".

Find attached the logs.



makeerror-4.4.0.90-powerpc-ibm-aix7.2.4.0-8cot.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on Cygwin

[Bruno Haible]

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'

  In all these failures, where we see an error message "Leftover temporary 
files" in GNU/Hurd,
  we see "Device or resource busy" in Cygwin.

* Other failures:

  - 1 failure in category 'misc/general4'.
Maybe because after deleting PATH, no 'echo' command is found any more.

Find attached the logs.


makeerror-4.4.0.90-x86_64-pc-cygwin-26a2.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on AIX 7.2

[Bruno Haible]

> * 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 seen this many years ago, in AIX 4 or AIX 5.)

config.h contains:
/* #undef USE_POSIX_SPAWN */

Replacing 'vfork ()' with 'fork ()' in src/job.c does not help.

Bruno

Re: OpenIndiana installation

[Bruno Haible]

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 package names that one needs to install.

I hope my writeup (below) helps.

Bruno

=== Solaris 11 OpenIndiana in VirtualBox 
OpenIndiana, a distro based on Illumos - roughly Solaris 11 compatible.

Download: 
http://dlc.openindiana.org/isos/hipster/20221123/OI-hipster-gui-20221123.iso

Getting started doc: http://docs.openindiana.org/handbook/getting-started/

Disk size: 16 GB
RAM size: 3 GB (with just 1.5 GB 'pkg install' runs out of RAM, with just 2 GB 
it hangs)


Run installer 'Install OpenIndiana'.

Root password: 

Login: **
Password: 

Host name: 

Eject CD/DVD. Reboot.

System > Preferences > Hardware > Power Management
  > On AC Power > Display > Put display to sleep when inactive for: Never
System > Preferences > Look and Feel > Windows
  > Behaviour > Window Selection > Select windows when the mouse moves over 
then: on

Reboot.

$ pkg search /usr/bin/gcc
$ pkg search /usr/bin/g++
$ pkg search /usr/include/stdio.h
$ pkg search /usr/bin/gdb
$ pkg search /usr/bin/emacs
$ pkg search /usr/bin/clang
See also https://pkg.openindiana.org/hipster/en/index.shtml

$ sudo pkg install developer/gcc-11
$ sudo pkg install system/header
$ sudo pkg install developer/debug/gdb
$ sudo pkg install editor/gnu-emacs
$ sudo pkg install developer/clang-13

Re: CentOS Stream installation

[Bruno Haible]

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
> time it freezes halfway through the install, and if it does go through
> the guest additions fail to compile their kernel modules (mismatched
> Linux kernel headers).

I never install the VirtualBox guest additions. The downside is that
sharing data is less comfortable (I use 'scp' each time), and that the
mouse handling is a bit more annoying.

Bruno

= CentOS 8 in VirtualBox ==
Use CentOS 8 stream 2022-10-05 from 
https://ftp.gwdg.de/pub/linux/centos/8-stream/isos/x86_64/

Disk size: 15 GB.

The installation menu is in a stupid order: Can only enable NTP servers
after networking is enabled! Therefore do things in this order:

Installation Destination:
Storage Configuration: Custom
Standard Partition  14 GiB (14336 MiB)  /  ext4
Standard Partition  1  GiB (1024 MiB)   swap

KDump:
Disable kdump.

Network & host name:
Enable networking.
Ethernet config: General > Enable "Connect automatically".
Host name: centos8s

Time & Date:
Set time zone.
Disable then Enable "Network Time".

Installation Source:
On the network, https://ftp.gwdg.de/pub/linux/centos/8-stream/BaseOS/x86_64/os/
URL type: repository URL
Deselect AppStream.
Select AppStream.

Software selection:
  Base Environment: Workstation
  Add-ons: Development Tools, Graphical Administration Tools

Root password:
  login: root
  password: 
  Press "Done" twice.

User settings:
  login: 
  password: 
  Select "Make this user administrator".
  Press "Done".

Click "Begin installation".

Wait for the installation to complete.

Power off. Eject CD.

Welcome wizard:
  Privacy: Location services: off.

Popup menu > Settings > Privacy > Screen Lock
Automatic screen lock = Off

Popup menu > Settings > Power > Power Saving
Blank screen = Never

Power Off. Reboot.

Activities > Software > Updates: Refresh. -> Up to date.

Activities > Software

Search: GNU Emacs, install
Search: gVim, install

$ dnf list
# Not needed:
#$ sudo dnf install make
#$ sudo dnf install gcc
#$ sudo dnf install gcc-c++

Power Off.

Re: CentOS Stream installation

[Bruno Haible]

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 data is less comfortable (I use 'scp' each time), and that
> > the mouse handling is a bit more annoying.
> 
> The problem is that I can't seem to open connections from my host
> machine to the guest machine: my host machine can't find the guests via
> any IP address I can come up with.

Yes, by default, in VirtualBox, you only have connectivity from the guest
to the host. For connectivity from the host to the guest, there appear to
be two approaches:
  - Give each guest a distinct IP address (means: list the guests in your
LAN's DHCP server), and choose a "bridged" network adapter for each
VM. Note: In my experience (with older versions of VirtualBox) this
works fine when the host has an Ethernet network card, but not with
a Wi-Fi network adapter.
  - Use the "Advanced > Port forwarding" setting, even with a "NAT" network
adapter. The host port number must be > 1024.
Web searches for "virtualbox ssh into vm" or "virtualbox ssh from host to guest"
give some pointers.

Also, don't forget that many guest OSes have a built-in firewall. If from
within the guest VM, "ssh localhost" works but from the host, ssh to the VM
never responds, then this is the problem. In this case, you will need to "open"
the port 22 there. For older Linux distro the command to do it is
  sudo iptables -I INPUT -p tcp -m tcp --dport 22 -j ACCEPT
For CentOS 8 probably something like
  sudo nft add rule inet firewalld filter_IN_public_allow tcp dport 22 accept

> And normally I don't have an SSH server running on my host machine,
> since I don't need to log into it from anywhere and it's more secure
> that way

Yeah, everyone has different preferences. Leading to different network
topologies in each case.

Bruno

Re: OpenIndiana installation

[Bruno Haible]

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++" told me that what I need is package
'developer/gcc/gcc-c++', so there I did
  sudo pkg install developer/gcc/gcc-c++

> So then I installed OpenIndiana based on your notes and that succeeded
> and I was able to build make and run the tests.
> 
> Unfortunately I wasn't able to reproduce the problem; all tests passed
> for me (I'm using a build where the ar issue is already fixed).  I
> tried with 1 CPU as well just to be sure.
> 
> Sigh!
> 
> I wonder what can be different about what I'm doing and what you're
> doing.

At this point I am out of clues too. Maybe it's related to the speed
of the CPU (e.g. execution speed vs. context switch speed ratio)?

> Maybe it's related to how the tests are run; I suppose you're
> using some sort of automated testing framework?  Maybe there's no TTY
> or something?  Can you briefly describe how the tests are invoked?

In a session with a TTY (GUI terminal in OpenIndiana, plain console in
Solaris 11.4), I run a /bin/sh script that contains these lines:

=
#!/bin/sh
test -f configure || { echo "This script must be invoked from a configurable 
package." 1>&2; exit 1; }
rm -rf build-64-gcc
mkdir build-64-gcc
cd build-64-gcc
$HOME/configure-64-gcc "$@" 2>&1 | tee log1 \
&& gmake 2>&1 | tee log2 \
&& gmake check 2>&1 | tee log3
=

Sometimes I also do "gmake check" without the redirection; there's
normally no difference between with and without redirection.

Bruno

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

[Bruno Haible]

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

[Bruno Haible]

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 said that. I don't even know
how to do this, within the framework of GNU make's test suite.

All I said was, comparing the Cygwin failures with the GNU/Hurd failures [1]:
  "In all these failures, where we see an error message "Leftover temporary
   files" in GNU/Hurd, we see "Device or resource busy" in Cygwin."

Bruno

[1] https://lists.gnu.org/archive/html/bug-make/2023-01/msg00134.html

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

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]

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

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

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

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

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

[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

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

[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, &found) == 
GLOB_NOMATCH)
  return 1;
globfree (&found);
  ]])],
   [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 troubleshooting

[Bruno Haible]

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 newbie users
and complex makefiles.

I know about, and have occasionally used, the GNU make options
  -n, --dry-run
  -d
  -p
  -t, --touch
and they don't fulfil my needs.

In particular, four aspects of transparency / debuggability / serviceability
are lacking in GNU make.

1) Print the total of the Makefile and all included Makefiles.
   Like what "gcc -E" does with C code.
   I don't need this when using Automake, because Automake resolves the
   'include' statements before generating a Makefile. But if people advocate
   to use GNU make without Automake, it becomes a requirement. As a developer,
   I don't want to check each 'include' statement, recursively, manually.
   A tool should do that.

   This would also answer a question on #gnu today:
   "Is there a way to figure out where the rule is coming from? The main
issue is "target file 'clean' has both : and :: entries. Stop." But
I'm unable to figure out where the last clean: target is coming from."

   Probably this facility should have an option to show the macroexpanded /
   not macroexpanded Makefile sources.

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

   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 information from a heap of output. It's not
   part of my skills.

3) Single-stepping or tracing function execution. One project (GNU libc)
   makes profound use of GNU make functions, and it was always painful
   for me to understand what results to expect from a complex use of
   $(foo ...). Even from the simple text-manipulating functions [2].

   There is an option --eval=STRING, but I don't think it fulfils the
   need.

4) A documentation chapter regarding troubleshooting, that explains
   how to understand what 'make' is doing in a particular case.
   Chapters 2-8 and 10-12 explain how to set up the input to 'make'.
   Chapters 9 and 13 explain operational aspects, but none goes into
   troubleshooting details.
   For a complex program like GNU make, probably at least 10 or 20 pages
   on this topic are needed.

Best regards,

Bruno

[1] https://www.airs.com/blog/archives/95
[2] https://www.gnu.org/software/make/manual/html_node/Functions.html

Re: GNU make troubleshooting

[Bruno Haible]

> 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 situations.
> 
>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 information from a heap of output. It's not
>part of my skills.

Just learned about the '--trace' option and I have two comments:

* It should be described in a chapter "Troubleshooting". Mentioning it
  in section "Summary of Options" is not enough.

* Some of its output is good; some of its output is useless:

$ rm mbrtoc32.o
$ make --trace mbrtoc32.o 
Makefile:1752: update target 'mbrtoc32.o' due to: ../../gllib/mbrtoc32.c 
/usr/include/stdc-predef.h ../config.h 
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdbool.h /usr/include/assert.h 
/usr/include/features.h /usr/include/features-time64.h 
/usr/include/x86_64-linux-gnu/bits/wordsize.h 
/usr/include/x86_64-linux-gnu/bits/timesize.h 
/usr/include/x86_64-linux-gnu/sys/cdefs.h 
/usr/include/x86_64-linux-gnu/bits/long-double.h 
/usr/include/x86_64-linux-gnu/gnu/stubs.h 
/usr/include/x86_64-linux-gnu/gnu/stubs-64.h uchar.h /usr/include/uchar.h 
stddef.h /usr/lib/gcc/x86_64-linux-gnu/11/include/stddef.h 
/usr/include/x86_64-linux-gnu/bits/types.h 
/usr/include/x86_64-linux-gnu/bits/typesizes.h 
/usr/include/x86_64-linux-gnu/bits/time64.h 
/usr/include/x86_64-linux-gnu/bits/types/mbstate_t.h 
/usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h 
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdint.h /usr/include/stdint.h 
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h 
/usr/include/x86_64-linux-gnu/bits/wchar.h 
/usr/include/x86_64-linux-gnu/bits/stdint-intn.h 
/usr/include/x86_64-linux-gnu/bits/stdint-uintn.h wchar.h /usr/include/wchar.h 
/usr/include/x86_64-linux-gnu/bits/floatn.h 
/usr/include/x86_64-linux-gnu/bits/floatn-common.h 
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdarg.h 
/usr/include/x86_64-linux-gnu/bits/types/wint_t.h 
/usr/include/x86_64-linux-gnu/bits/types/__FILE.h 
/usr/include/x86_64-linux-gnu/bits/types/FILE.h 
/usr/include/x86_64-linux-gnu/bits/types/locale_t.h 
/usr/include/x86_64-linux-gnu/bits/types/__locale_t.h 
/usr/include/x86_64-linux-gnu/bits/wchar2.h /usr/include/string.h 
/usr/include/strings.h /usr/include/x86_64-linux-gnu/bits/strings_fortified.h 
/usr/include/x86_64-linux-gnu/bits/string_fortified.h /usr/include/wctype.h 
/usr/include/x86_64-linux-gnu/bits/wctype-wchar.h 
/usr/include/x86_64-linux-gnu/bits/endian.h 
/usr/include/x86_64-linux-gnu/bits/endianness.h ../../gllib/attribute.h 
/usr/include/errno.h /usr/include/x86_64-linux-gnu/bits/errno.h 
/usr/include/linux/errno.h /usr/include/x86_64-linux-gnu/asm/errno.h 
/usr/include/asm-generic/errno.h /usr/include/asm-generic/errno-base.h 
/usr/include/x86_64-linux-gnu/bits/types/error_t.h stdlib.h 
/usr/include/stdlib.h /usr/include/x86_64-linux-gnu/bits/waitflags.h 
/usr/include/x86_64-linux-gnu/bits/waitstatus.h sys/types.h 
/usr/include/x86_64-linux-gnu/sys/types.h 
/usr/include/x86_64-linux-gnu/bits/types/clock_t.h 
/usr/include/x86_64-linux-gnu/bits/types/clockid_t.h 
/usr/include/x86_64-linux-gnu/bits/types/time_t.h 
/usr/include/x86_64-linux-gnu/bits/types/timer_t.h /usr/include/endian.h 
/usr/include/x86_64-linux-gnu/bits/byteswap.h 
/usr/include/x86_64-linux-gnu/bits/uintn-identity.h 
/usr/include/x86_64-linux-gnu/sys/select.h 
/usr/include/x86_64-linux-gnu/bits/select.h 
/usr/include/x86_64-linux-gnu/bits/types/sigset_t.h 
/usr/include/x86_64-linux-gnu/bits/types/__sigset_t.h 
/usr/include/x86_64-linux-gnu/bits/types/struct_timeval.h 
/usr/include/x86_64-linux-gnu/bits/types/struct_timespec.h 
/usr/include/x86_64-linux-gnu/bits/select2.h 
/usr/include/x86_64-linux-gnu/bits/pthreadtypes.h 
/usr/include/x86_64-linux-gnu/bits/thread-shared-types.h 
/usr/include/x86_64-linux-gnu/bits/pthreadtypes-arch.h 
/usr/include/x86_64-linux-gnu/bits/atomic_wide_counter.h 
/usr/include/x86_64-linux-gnu/bits/struct_mutex.h 
/usr/include/x86_64-linux-gnu/bits/struct_rwlock.h /usr/include/alloca.h 
/usr/include/x86_64-linux-gnu/bits/stdlib-bsearch.h 
/usr/include/x86_64-linux-gnu/bits/stdlib-float.h 
/usr/include/x86_64-linux-gnu/bits/stdlib.h ../../gllib/localcharset.h 
../../gllib/streq.h ../../gllib/hard-locale.h locale.h /usr/include/locale.h 
/usr/include/x86_64-linux-gnu/bits/locale.h ../../gllib/setlocale_null.h 
../../gllib/arg-nonnull.h
gcc -ftrapv -DHAVE_CONFIG_H -I. -I../../gllib -I..  -DGNULIB_STRICT_CHECKING=1 
-I/media/develdata/devel/inst-x86_64-64/include -Wall  -g -O2 -MT mbrtoc32.o 
-MD -MP -MF .deps/mbrtoc32.Tpo -c -o mbrtoc32.o ../../gllib/mbrtoc32.c
mv -f .deps/mbrtoc32.Tpo .deps/mbrtoc32.Po

The part "Makefile