AmigaOS support

[mark sealey]

Why are you dropping support for the AmigaOS in the next release of GNU ?

Hopefully you will reconsider ?

Kind regards

Mark Sealey

[bug #63315] Test failures with 4.4 on OpenBSD

[Paul D. Smith]

Follow-up Comment #3, bug #63315 (project make):

Thank you for the assist Brad; I have found the problem and will fix it in the
next release.

FYI:


diff --git a/src/function.c b/src/function.c
index f0ef3434..893e583d 100644
--- a/src/function.c
+++ b/src/function.c
@@ -2801,7 +2801,7 @@ define_new_function (const floc *flocp, const char
*name,
  _("Invalid maximum argument count (%u) for function %s"), max,
name);

   ent = xmalloc (sizeof (struct function_table_entry));
-  ent->name = name;
+  ent->name = xstrdup (name);
   ent->len = (unsigned char) len;
   ent->minimum_args = (unsigned char) min;
   ent->maximum_args = (unsigned char) max;
@@ -2812,7 +2812,11 @@ define_new_function (const floc *flocp, const char
*name,
   ent->fptr.alloc_func_ptr = func;

   ent = hash_insert (&function_table, ent);
-  free (ent);
+  if (ent)
+{
+  free ((void*)ent->name);
+  free (ent);
+}
 }

 void



___

Reply to this item at:

  

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

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

[anonymous]

Follow-up Comment #5, bug #63307 (project make):

That previous comment was meant to read SIGPIPE, not SIGIGN, of course :)


___

Reply to this item at:

  

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

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

[anonymous]

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

Nice idea to just have a signal handler that does nothing. If SIGIGN was
ignored before make was started though, it should remain ignored, even for
make's children, see also
 in reply
to Andreas Schwab's first patch. Correct me if I am wrong, but I think your
patch re-enables it in that case?


___

Reply to this item at:

  

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

4.4: embeds volatile information in MAKEFLAGS

[Steffen Nurpmeso]

Hello.

CRUX-Linux did not yet update make to 4.4; one of the project
leaders said

 13:23 < jue> stenur: building of s-mail is broken with make 4.4
 13:23 < jue> ... glibc as well

When looking into this now for my s-nail MUA i saw

  #?0|kent:s-nail-14.9.24$ ../make-4.4/make all -j4
  ...
All good
  ...
  #?0|kent:s-nail-14.9.24$ make distclean
  make[1]: Entering directory '/tmp/x/s-nail-14.9.24/.obj'
  make[1]: *** Cannot open jobserver /tmp/GMfifo31074: No such file or 
directory.  Stop.
  make[1]: Leaving directory '/tmp/x/s-nail-14.9.24/.obj'
  make: *** [makefile:40: distclean] Error 2

It seems GNU make now embeds volatile information into $MAKEFLAGS,
but refrains from working if that is invalid.
I see NEWS is saying

  You can force GNU Make to use the simple pipe-based jobserver (perhaps if
  you are integrating with other tools or older versions of GNU Make) by
  adding the '--jobserver-style=pipe' option to the command line of the
  top-level invocation of GNU Make, or via MAKEFLAGS or GNUMAKEFLAGS.
  To detect this change search for 'jobserver-fifo' in the .FEATURES variable.

but this requires changes to the build system, and a new release.

I wonder, or, to be honest, it is my opinion that GNU make should
reset this part of MAKEFLAGS in at least the ENOENT case?

A nice sunday i wish.
(I am not subscribed.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 4.4: embeds volatile information in MAKEFLAGS

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20221105222339.z0b2x%stef...@sdaoden.eu>:
 ...
 |  #?0|kent:s-nail-14.9.24$ ../make-4.4/make all -j4
 |  ...
 |All good
 |  ...
 |  #?0|kent:s-nail-14.9.24$ make distclean
 |  make[1]: Entering directory '/tmp/x/s-nail-14.9.24/.obj'
 |  make[1]: *** Cannot open jobserver /tmp/GMfifo31074: No such file \
 |  or directory.  Stop.
 |  make[1]: Leaving directory '/tmp/x/s-nail-14.9.24/.obj'
 |  make: *** [makefile:40: distclean] Error 2
 |
 |It seems GNU make now embeds volatile information into $MAKEFLAGS,
 |but refrains from working if that is invalid.

This hinders build systems which aim in being portable and easy,
in that users simply call "make" and that calls some shell script
for configuration by itself (instead of the typical GNU style
"./configure && make && make install).
I do, for example, and in the shell script i do

  COMMLINE="${*}"

in order to pick up things the user gave on the command line.
(The software can be configured via command line arguments, say

  $ make OPT_POP3=no OPT_SMTP=require tangerine)

 ...
 |I wonder, or, to be honest, it is my opinion that GNU make should
 |reset this part of MAKEFLAGS in at least the ENOENT case?
 ...

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

[Dmitry Goncharov]

Follow-up Comment #6, bug #63307 (project make):

> If SIGIGN was ignored before make was started though, it should remain
ignored, even for make's children, see also
 in reply
to Andreas Schwab's first patch. Correct me if I am wrong, but I think your
patch re-enables it in that case?

My patch causes the disposition of sigpipe to be set to SIG_DFL in the new
process. See https://pubs.opengroup.org/onlinepubs/9699919799/, specifically
"Signals set to be caught by the calling process image shall be set to the
default action in the new process image (see )."

This desire to have the default disposition is intentional. Some of the
reasons are explained in update 2. Other reasons are the desire to avoid
complexity in make. Especially when there is no clear need for that
complexity.


In regards to the specific impl of Andreas's 2nd patch there are 2 points.

1. That patch fails to restore the disposition in the case of make
re-executing itself (in order to read an updated makefile).
This could be fixed by calling sigaction before execve, but that'd not be
atomic.

2. That patch uses posix_spawnattr_setsigdefault to set the disposition for a
child process (when make uses posix_spawn). This fails the purpose of the
patch, if make was invoked with sigpipe disposition of SIG_HOLD.

Fixing those deficiencies is not that cheap. In the end, i didn't see any
benefit for make to go through that trouble of restoring sigpipe disposition
for its children and i proposed this simple fix.

Unlike attempts to restore, one nice property of the sighandler patch is that,
if more calls to exec are introduced to make, the patch will still work for
all of them.


___

Reply to this item at:

  

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

Re: 4.4: embeds volatile information in MAKEFLAGS

[Dmitry Goncharov]

On Sat, Nov 5, 2022 at 6:24 PM Steffen Nurpmeso  wrote:
>   make[1]: *** Cannot open jobserver /tmp/GMfifo31074: No such file or 
> directory.  Stop.

Can you please tell us how to reproduce?

regards, Dmitry

Re: [bug #63307] make 4.4 passes ignored SIGPIPE on to children

[Philip Guenther]

On Sat, Nov 5, 2022 at 1:34 PM Dmitry Goncharov 
wrote:

> Follow-up Comment #6, bug #63307 (project make):
>
> > If SIGIGN was ignored before make was started though, it should remain
> ignored, even for make's children, see also
>  in
> reply
> to Andreas Schwab's first patch. Correct me if I am wrong, but I think your
> patch re-enables it in that case?
>
> My patch causes the disposition of sigpipe to be set to SIG_DFL in the new
> process. See https://pubs.opengroup.org/onlinepubs/9699919799/,
> specifically
> "Signals set to be caught by the calling process image shall be set to the
> default action in the new process image (see )."
>
> This desire to have the default disposition is intentional. Some of the
> reasons are explained in update 2. Other reasons are the desire to avoid
> complexity in make. Especially when there is no clear need for that
> complexity.
>

This is a change in behavior: previously, make didn't alter the disposition
of SIGPIPE and a build system could set it to SIG_IGN and have all the
invoked recipes inherit that.  As part of saying that make will ignore
SIGPIPE, you've decided to impose a rule that the rest of the build system
has to deal with it in the recipes instead of permitting a pass-through.
That's an unnecessary and user-unfriendly imposition.


In regards to the specific impl of Andreas's 2nd patch there are 2 points.
>
> 1. That patch fails to restore the disposition in the case of make
> re-executing itself (in order to read an updated makefile).
> This could be fixed by calling sigaction before execve, but that'd not be
> atomic.


> 2. That patch uses posix_spawnattr_setsigdefault to set the disposition
> for a
> child process (when make uses posix_spawn). This fails the purpose of the
> patch, if make was invoked with sigpipe disposition of SIG_HOLD.
>

(SIG_HOLD?  That's not a real disposition (in posix) but rather part of an
obsolete version of a mechanism standardized as sigprocmask() and
orthogonal to the disposition (ignore/default/catch).)



> Fixing those deficiencies is not that cheap. In the end, i didn't see any
> benefit for make to go through that trouble of restoring sigpipe
> disposition
> for its children and i proposed this simple fix.
>
> Unlike attempts to restore, one nice property of the sighandler patch is
> that,
> if more calls to exec are introduced to make, the patch will still work for
> all of them.
>

Setting the disposition of SIGPIPE to be caught with a do-nothing routine
is a good idea.  Can you just skip that if the disposition is SIG_IGN at
start?  Then a SIG_IGN will be inherited but the disposition will otherwise
be reset by execve.

Re: 4.4: embeds volatile information in MAKEFLAGS

[Steffen Nurpmeso]

Dmitry Goncharov wrote in
 :
 |On Sat, Nov 5, 2022 at 6:24 PM Steffen Nurpmeso  wrote:
 |>   make[1]: *** Cannot open jobserver /tmp/GMfifo31074: No such file \
 |>   or directory.  Stop.
 |
 |Can you please tell us how to reproduce?

Well it is a bit hard in a short time.
But like i wrote in my second message.
You could, however, easily test with my mailer, the CRUX recipe is

  name=mailx
  version=14.9.24
  release=1
  source=(https://www.sdaoden.eu/downloads/s-nail-$version.tar.xz)

  build() {
  cd s-nail-$version

  make config \
  VAL_SID= \
  VAL_MAILX=mailx \
  VAL_PREFIX=/usr \
  VAL_LIBEXECDIR=/usr/lib/mailx \
  OPT_AUTOCC=no

  make DESTDIR=$PKG install

^ I told him he can join the two invocations into one, this would
work with GNU make 4.4

  chmod -R u+w $PKG

  ln -s mailx   $PKG/usr/bin/Mail
  ln -s mailx   $PKG/usr/bin/mail
  ln -s mailx.1 $PKG/usr/share/man/man1/mail.1
  }

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 4.4: embeds volatile information in MAKEFLAGS

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20221105230326.qijdr%stef...@sdaoden.eu>:
 |Dmitry Goncharov wrote in
 | :
 ||On Sat, Nov 5, 2022 at 6:24 PM Steffen Nurpmeso  \
 ||wrote:
 ||>   make[1]: *** Cannot open jobserver /tmp/GMfifo31074: No such file \
 ||>   or directory.  Stop.
 ||
 ||Can you please tell us how to reproduce?
 ...
 |You could, however, easily test with my mailer, the CRUX recipe is
 ...
 |^ I told him he can join the two invocations into one, this would
 |work with GNU make 4.4

This will not work for other Linux distributions or operating
system packages, as these often separate per see, so that you have
configuration, build, install, and test in separately addressable
packaging rules.

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[bug #63315] Test failures with 4.4 on OpenBSD

[Brad Smith]

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

Thanks.

What about the temp_stdin test?


___

Reply to this item at:

  

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