Re: Bug with double slashes

> From: Paul Smith > Date: Sat, 06 Jun 2009 02:01:03 -0400 > Cc: bug-make@gnu.org > Reply-To: psm...@gnu.org > > Less obvious is which of the various ways it could be fixed is the right > way. Should we stop "cleaning" these paths altogether, to work around > the bug in glibc glob()? I think if

Re: Bug with double slashes

On Sat, 2009-06-06 at 04:09 -0400, Eli Zaretskii wrote: > Might as well bring some glibc expert on board for this discussion. > (Sorry, I don't have a recommendation who might that be.) They could > put the glibc behavior into perspective, and also advise about other > implementations of `glob'.

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Update of bug #15919 (project make): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #30: I debugged this and

[bug #25703] .LIBPATTERNS is not pattern dependent.

Update of bug #25703 (project make): Item Group: Bug => Enhancement ___ Follow-up Comment #1: I'm marking this as an enhancement, since the code works as designed. I agree it would be nice to

[bug #22010] The increased stack rlimit is inherited by the subprocesses to make.

Update of bug #22010 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #22434] Consider a dependancy as target file and try to make the file

Update of bug #22434 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #6: This problem is happe

[bug #22442] Old-style cancelation of implicit rules

Update of bug #22442 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Closing. Feel free t

[bug #23361] Infinite loop when including file that depends on a phony target

Update of bug #23361 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Dave's comment is cor

[bug #23210] target/dependants with equal mtime

Update of bug #23210 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: The problem is that t

[bug #21854] Dependency to a -l to be made in a not yet existing directory doesn't match(?)

Update of bug #21854 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => CVS

[bug #21823] Potential NULL pointer dereference on hash.c, hash_insert

Update of bug #21823 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release: