[bug #40361] make 4.0 under hpux 11.31 no longer prints output correctly
Follow-up Comment #1, bug #40361 (project make): I'm not sure what to say about this: clearly this doesn't happen on the systems we have access to (Linux, Solaris, Mac OS, Windows). I, at least, don't have any access to an HPUX system. Without being able to reproduce it ourselves we'll need someone to do the investigation. Probably easiest would be for you (or someone who can reproduce this issue) to email the bug-make@gnu.org mailing list with details so we can have a discussion. My first suggestion would be to run env | grep MAKE and see if there are any unusual make-related environment variables. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40361 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #40361] make 4.0 under hpux 11.31 no longer prints output correctly
Follow-up Comment #2, bug #40361 (project make): 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? ___ Reply to this item at: http://savannah.gnu.org/bugs/?40361 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #40361] make 4.0 under hpux 11.31 no longer prints output correctly
Follow-up Comment #3, bug #40361 (project make): Given that there are no env.var. settings that are odd, I'd agree with you. You show results for 3.81; have you tried 3.82? I find it very strange, the output you do get. I have no idea where something like that would come from, at all. In fact your makefile commands are simple enough that make won't even invoke the shell: it will simply fork/exec those programs directly. If you remove the rm file.c from the rule, is file.c created? That is, is make actually invoking the commands just not printing the output? If you add a command like echo hi, do you see the output printed (hi)? One thing you might try is to go to output.c and find the function output_init(), and comment out the two invocations of set_append_mode(), one for stdout and one for stderr. Maybe there's something broken about the way HPUX sets append mode on open file descriptors. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40361 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #40361] make 4.0 under hpux 11.31 no longer prints output correctly
Follow-up Comment #5, bug #40361 (project make): Removing those set_append_mode() calls didn't appear to make any difference. I've attached a log from tusc (the HP-UX equivalent of strace/truss etc.) showing the invocations during the sample I described in the first post - perhaps that may help you to diagnose (file #29459) ___ Additional Item Attachment: File name: tusc.log Size:85 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?40361 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #40361] make 4.0 under hpux 11.31 no longer prints output correctly
Follow-up Comment #7, bug #40361 (project make): Sure. Updated tusc.log attached with -p -v added (file #29466) ___ Additional Item Attachment: File name: tusc.log Size:125 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?40361 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #40361] make 4.0 under hpux 11.31 no longer prints output correctly
On Thu, Oct 24, 2013 at 3:43 PM, Frank Heckenbach invalid.nore...@gnu.org wrote: 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. I no longer have notes about what version I saw it in, but HP-UX's vsnprintf/snprintf would, when the buffer wasn't large enough, return -1 instead of the number of chars that would have been written. I think it also flubbed handling of buflen==0 as the workaround code we used would make a first try passing a buflen of 1 and a single char buf instead of a buflen of zero and NULL. Or maybe that part was a bug in AIX. Hmm... Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
