http://git.savannah.gnu.org/cgit/make.git/commit/?id=757849cd93a9bc361a5113e3aaafe516773aad44

Hello everyone,

Please have a look at my patch for bug #40515. The culprit is vsnprintf().

On HP-UX, this function returns -1 if the buffer is not big enough, and vfmtconcat() wasn't handling that at all.

I would be surprised if it's va_copy().  On the other hand I'm surprised that a UNIX variant in 2013 doesn't comply with a C standard which is 14+ years old now...  I sort of expect that from Windows as they've all but abandoned C, but not a UNIX system.

On the other hand we do try to meet C89 compliance (at least for the standard library and language).  There are two alternative non-standard semantics of vsnprintf() that I'm aware of: one where it returns <0 if the buffer is too small (Windows does it this way) and the other where it returns the number of bytes written and doesn't write the last nul byte (like strncpy).

We may need to switch to gnulib functions or else avoid the *nprintf() variants.  I'll look into this.

Although, slightly odd that the 'Entering directory' appeared after the 'touch file.c' - although I presume that is just related to the temporary code replacement with vprintf causing an immediate print

Another thing that changed in the course of the output patches is that messages are now generated in vfmtconcat() using vsnprintf() as well as va_copy(), both C99 and at least the latter AFAIK not very widely used.

For testing you could try replacing the body of vfmtconcat() with "vprintf (fmt, args);". (Keep the return statement to avoid a compiler warning; the returned value isn't actually used.) This will break output-sync, of course, but if the messages are correct then, we've found the culprits.

Hrm.  Not much of interest here.  What I'm beginning to think is that there's some kind of memory corruption or something, so that when make thinks it's printing out the command that it's about to execute it's instead printing out some other random string buffer.  I'm not sure that it's really related to the output changes in the end.

That would definitely explain this, since there's no place anywhere in the GNU make code that we ever print "$(IFS)" for example, and the output we get (three different output strings) is the same as the number of command lines make would print.

However, I've run make under valgrind etc. and not found any memory issues.  So this is very much a mystery to me still.

Wow, that is extremely bizarre.  I just have no idea where that output is coming from, or going to.  Can you re-run and add the "-p" option so that each line of output has a PID next to it?  I wonder if something else is printing those values.  I assume you did run it with "-f" and "-o" flags already (I see that there is a handy example specifically for "make" in the tusc man page :-p :-))

Also you might try adding "-v".  I don't know if the extra verbosity will be useful or not.

Yep the output files are created succesfully, so it is definitely just the output messages that are not getting through. I haven't tried 3.82, but I can do.

I have succesfully completed a large full product build with 4.0, and all the output was successfully generated, but the make.log was similarly very spartan to the reduced testcase I posted here.

I'll take a look at your suggested patches to output_init() shortly and get back to you.

On a related note, `make check` fully passed on 3.81, but fails on most tests on 4.00 due to the missing stdout messages.

I'm happy to grab whatever debug that may be required.

`env | grep MAKE` shows that no make-related environment variables have been set.

I'm guessing this regression is most likely to have been caused during the consolidation of output generators into output.c perhaps something c99 that HP haven't implemented correctly?

Easily demonstrable with simple pair of Makefiles

Built for ia64-hp-hpux11.31

.
├── Makefile
└── subdir
    └── Makefile

$ cat Makefile
all:
        $(MAKE) -C subdir

$ cat subdir/Makefile
all:
        touch file.c
        rm file.c

$ /opt/gnumake-3.81/bin/make -rR
/opt/gnumake-3.81/bin/make -C subdir
make[1]: Entering directory `/tmp/a/subdir'
touch file.c
rm file.c
make[1]: Leaving directory `/tmp/a/subdir'

$ /opt/tools/gnumake-4.0/bin/make -rR
$(IFS)make[1]: Entering directory '/tmp/a/subdir'
/bin/sh/bin/shmake[1]: Leaving directory '/tmp/a/subdir'

Notice the '/bin/sh' entries printed for the two rules and the odd $(IFS) printing as well