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

[Eric Blake]

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

For reference, another failure caused by make's change in behavior:
https://listman.redhat.com/archives/libguestfs/2023-January/030474.html


___

Reply to this item at:

  

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

bug in $(wildcard) with trailing slash

[Eric Blake]

Make fails to restrict output to just directories when a wildcard
contains both a trailing slash and internal slashes, even though it does
the right thing with no internal slashes.

$ mkdir /tmp/example
$ cd /tmp/example/
$ touch a
$ mkdir b
$ printf 'all:\n\t@echo $(wildcard */)' | make -f -
b/
$ printf 'all:\n\t@echo $(wildcard ./*/)' | make -f -
./b/ ./a

Both invocations should have omitted a, since the trailing slash cannot
match a non-directory (other than a symlink to a directory).

$ make --version | head -n2
GNU Make 3.82
Built for x86_64-redhat-linux-gnu

I encountered this while writing a macro for libvirt; as a workaround, I
ended up using a trailing /. to force just directories, then using
$(patsubst) to strip things back to what I wanted in the first place.

cross_dirs=$(patsubst $(srcdir)/src/%.,%,$(wildcard $(srcdir)/src/*/.))

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org





signature.asc
Description: OpenPGP digital signature
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: High-Precision NFS Timestamps

[Eric Blake]

[adding bug-make, replies can drop automake]

On 01/12/2011 03:08 PM, Eric Reischer wrote:
 I recently upgraded our NFS fileserver to an ext4 filesystem, and since
 then we've been having clock skew warnings from make (3.81).  Because
 the ext3 filesystem that was previously running on the NFS server didn't
 support high-precision timestamps, we didn't have clock skew warnings
 because an hourly cron job kept the clocks in relatively close sync. 
 However, since ext4 does support sub-second timestamps, we're getting
 warnings about clock skews on the order of a few milliseconds.  I tried
 adding our target objects to the .LOW_RESOLUTION_TIME target, however
 now we're getting a warning about
 
 make: *** Warning: .LOW_RESOLUTION_TIME file .lib_deps has a high
 resolution time stamp
 make:  warning: Clock skew detected.  Your build may be incomplete.
 
 Since asking to have system clocks of NFS clients and servers synced to
 sub-millisecond precision is a bit excessive, is there a way (or feature
 request: could there be a way) to set the threshold for clock skews
 either via a runtime Makefile directive, or an environment variable?  I
 can't see any other way to eliminate these warnings without reverting
 back to ext3 (which isn't happening).  If it's a hard-coded value, there
 should be at least a little room for slop in there (~5 milliseconds?)
 due to network lag, etc.  Even on a point-to-point network, there's
 going to be one-way transit times of a millisecond or two.

This is more likely a make issue than an automake issue.

That said, NFS timestamps are indeed a source of pain, and gnulib has
recently put in quite a bit of work dealing with timestamp skew across
NFS (including code to ignore relatively close timestamps, rather than
insist that sub-millisecond differences represent skew); some of that
may be worth incorporating into the make code base if it isn't there
already.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Porting make to HP NonStop

[Eric Blake]

On 09/09/2010 06:43 AM, Schmitz, Joachim wrote:

Hi there

I just tried to port make-3.82 to HP-Nonstop. I got it to work (almost) with 
the following minor changes:

diff -u ./config/config.sub.orig ./config/config.sub
--- ./config/config.sub.orig2010-07-28 00:42:11.0 -0500
+++ ./config/config.sub 2010-09-08 02:14:41.0 -0500
@@ -860,6 +860,9 @@
 np1)
 basic_machine=np1-gould
 ;;
+   nse-tandem)
+   basic_machine=nse-tandem
+   ;;


Thanks for the patch.  However, config.sub patches should be sent to 
config-patc...@gnu.org (not autoconf-patches), as documented in 
'config.sub --help'.  The next Autoconf release will automatically pick 
up the latest upstream config.sub.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

Re: GNU make 3.82 is now available

[Eric Blake]

On 07/28/2010 12:50 AM, Paul Smith wrote:
 * WARNING: Backward-incompatibility!
   The POSIX standard for make was changed in the 2008 version in a
   fundamentally incompatible way: make is required to invoke the shell as if
   the '-e' flag were provided.  Because this would break many makefiles that
   have been written to conform to the original text of the standard, the
   default behavior of GNU make remains to invoke the shell with simply '-c'.
   However, any makefile specifying the .POSIX special target will follow the
   new POSIX standard and pass '-e' to the shell.  See also .SHELLFLAGS
   below.

It's not obvious from this announcement (and I haven't been following
the make lists) whether you are aware: The POSIX 2008 wording has a bug.
 The intent of the Austin Group is that -e must NOT be provided if some
other mechanism ignores errors for a particular shell invocation (such
as starting a command with - or invoking 'make -i'):
 http://austingroupbugs.net/view.php?id=257

 
 * New special variable: .SHELLFLAGS allows you to change the options passed
   to the shell when it invokes recipes.  By default the value will be -c
   (or -ec if .POSIX is set).

Given that recent POSIX ruling, I'm not sure what impact it should have
on .SHELLFLAGS.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: autoconf-2.62: `make install' fails if file system is case insensitive

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[adding bug-automake and bug-make; this is
http://lists.gnu.org/archive/html/bug-autoconf/2008-05/msg0.html]

According to Keith Marshall on 5/9/2008 2:16 PM:
| If autoconf's Makefile is processed by a GNU make-3.81, which has been
| configured to respect a case insensitive file system, (IMO, the correct
| configuration for use on MS-Windows, among other other systems which
| also have such file systems), and the build is configured directly
| within the source directory, then `make install' fails thus:
|
|   $ make install
|   Makefile:678: warning: overriding commands for target `install'
|   Makefile:574: warning: ignoring old commands for target `install'
|   /bin/sh /home/rgbl0264/foobar/foo/autoconf-2.62/build-aux/missing \
|   --run makeinfo --no-headers --no-validate --no-split  -o install \
|   ./doc/install.texi

Looking further at this, what happens with your case-insensitive make when
running 'make dist' on a project built with 'automake --gnu'?  There,
automake adds an automatic dependency on all 'dist*' targets to unadorned
INSTALL.  Does that mean that 'make dist' will attempt to install the
package when run on MSYS?  Will it just be a no-op because the file
INSTALL already exists?  Is this something that automake needs to address,
by outputting $(abs_srcdir)/INSTALL rather than plain INSTALL in the
dependencies of distdir?

|
| This problem was recently reported by a user on the MinGW users ML:
| http://thread.gmane.org/gmane.comp.gnu.mingw.user/26315
|
| It is not apparent when performing a VPATH build, but is reproducible
| when building in the source directory, both for autoconf-2.62, and for
| earlier versions, (I've also confirmed this for autoconf-2.61).

Because in a VPATH build, $(srcdir)/INSTALL is different than ./INSTALL,
and it looks like case-insensitive GNU make is treating 'make install' and
'make ./INSTALL' as synonyms.  Maybe this is also something that should be
addressed in GNU make, as case-insensitivity makes following GNU Coding
Standards rather difficult?  GNU Coding Standards require the existence of
both 'make install' and './INSTALL'.

|
| This issue may be resolved by replacing each of the three references to
| `$(srcdir)/INSTALL', in the Makefile, by `$(abs_srcdir)/INSTALL'.  I've
| confirmed this, by making the appropriate changes in Makefile.in, and
| then successfully repeating the `./configure  make  make install'
| sequence under MSYS-1.0.11, (with case-insensitive GNU make-3.81), in
| the autoconf-2.62 source directory, on MS-Win2K.  The attached patch,
| against released autoconf-2.62's Makefile.am, will introduce the same
| change, on next Makefile.in regeneration.

That worked for 'make install', but broke 'make dist'; I'm trying to
figure out whether adding:

INSTALL: $(abs_srcdir)/INSTALL

to autoconf's Makefile.am will be making the problem any worse (at least
it fixes the 'make dist' regression when using the normal case-sensitive
GNU make).  Maybe the short answer is that on MSYS (or anywhere else with
case-insensitive GNU make), you should not expect 'make dist*' to work.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhFlgIACgkQ84KuGfSFAYB1ygCfUvdwoLNeVI3ra4TMb0A1d9m4
YFwAn0m/eukAKMi7LuxKb7wKhidq6yzq
=C2vT
-END PGP SIGNATURE-


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