[bug #38420] $(realpath ...) doesn't recover from signals

2013-03-11 Thread anonymous
Follow-up Comment #6, bug #38420 (project make): In case anyone attempts to use the posted workaround, the calls to variable_buffer_output can be interrupted which will set errno = EINTR. When this happens, gmake gets into a death spiral calling xrealloc, doubling the amount of memory allocated

[bug #38420] $(realpath ...) doesn't recover from signals

2013-02-27 Thread Brian Vandenberg
Follow-up Comment #3, bug #38420 (project make): Paul, You're spot on. It is Solaris / NFS 3. In the interim I'm using a build with the fix I suggested. Do you know of a workaround for this that wouldn't require deploying a modified version of make?

[bug #38420] $(realpath ...) doesn't recover from signals

2013-02-27 Thread Paul D. Smith
Follow-up Comment #4, bug #38420 (project make): The only option I can think of is using $(shell ...) to determine the real path rather than the built-in realpath function. This will be slower, but more reliable (as far as I'm aware all the EINTR issues with shell have long since been solved).

Re: [bug #38420] $(realpath ...) doesn't recover from signals

2013-02-27 Thread Philip Guenther
On Wed, Feb 27, 2013 at 9:44 AM, Brian Vandenberg invalid.nore...@gnu.org wrote: Follow-up Comment #3, bug #38420 (project make): You're spot on. It is Solaris / NFS 3. In the interim I'm using a build with the fix I suggested. Do you know of a workaround for this that wouldn't

[bug #38420] $(realpath ...) doesn't recover from signals

2013-02-27 Thread Brian Vandenberg
Follow-up Comment #5, bug #38420 (project make): Paul, I'm using `realpath` for defensive coding purposes. I'm using a pattern rule of the form: %.so : $(if $(realpath $(filter %.o,${^})),,$(warning No dependencies specified for ${@})@false) recipe goes here ... where the dependencies

Re: [bug #38420] $(realpath ...) doesn't recover from signals

2013-02-27 Thread Brian Vandenberg
On Wed, Feb 27, 2013 at 11:36 AM, Philip Guenther guent...@gmail.com wrote: On Wed, Feb 27, 2013 at 9:44 AM, Brian Vandenberg invalid.nore...@gnu.org wrote: Follow-up Comment #3, bug #38420 (project make): You're spot on. It is Solaris / NFS 3. In the interim I'm using a build with the

Re: [bug #38420] $(realpath ...) doesn't recover from signals

2013-02-27 Thread Paul Smith
On Wed, 2013-02-27 at 12:47 -0700, Brian Vandenberg wrote: What it doesn't make clear is, if it's configured with 'nointr' will that just cause the system function to block? That seems the most plausible. Correct. With nointr, you won't be able to (for example) ^C a program that is hung

[bug #38420] $(realpath ...) doesn't recover from signals

2013-02-27 Thread Paul D. Smith
Update of bug #38420 (project make): Item Group:None = Bug Status:None = Fixed Assigned to:None = psmith Open/Closed:

[bug #38420] $(realpath ...) doesn't recover from signals

2013-02-26 Thread Brian Vandenberg
URL: http://savannah.gnu.org/bugs/?38420 Summary: $(realpath ...) doesn't recover from signals Project: make Submitted by: phantal Submitted on: Tue 26 Feb 2013 10:21:44 PM GMT Severity: 3 - Normal Item

[bug #38420] $(realpath ...) doesn't recover from signals

2013-02-26 Thread Brian Vandenberg
Follow-up Comment #1, bug #38420 (project make): Also, need to include errno.h. ___ Reply to this item at: http://savannah.gnu.org/bugs/?38420 ___ Message sent via/by Savannah

[bug #38420] $(realpath ...) doesn't recover from signals

2013-02-26 Thread Paul D. Smith
Follow-up Comment #2, bug #38420 (project make): Let me guess, you're working on Solaris? And probably using an NFS-mounted filesystem? See, for example: http://lists.gnu.org/archive/html/help-make/2006-04/msg00023.html However, you're right that we should be doing a better job of error