Re: GNU make release candidate 3.99.90 available

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Mon, 20 May 2013 09:24:40 -0400
> 
> On Fri, 2013-05-17 at 22:35 +0300, Eli Zaretskii wrote:
> > When a dynamic extension is being remade, it is unloaded by calling
> > unload_file.  The latter looks up its argument in a linked list of
> > loaded objects.  Now, unload_file is called with file->name as its
> > argument; is it 100% sure that this string will be identical to what
> > was used in load_file?  IOW, do we never change relative file names to
> > absolute ones (or vice versa), mirror backslashes to forward slashes,
> > or do any other transformations that produce a different string which
> > points to the same file?  If we can do such transformations, unloading
> > will be unreliable.
> 
> Yes, I thought about this as I was making the change.
> 
> I believe it is true that the initial pathname will be identical.
> However there are ways in which the path might change: for example
> through use of VPATH.  I'm not exactly sure how all this will play out
> so it needs some testing.
> 
> I still don't want to add back the pointer to the struct.  Memory usage
> by GNU make is becoming a sore spot, especially as larger and larger
> build systems start to move to non-recursive make.  If necessary we'll
> need to make the list a bit more sophisticated so we can add new
> elements to it if/when we rename targets.

How about if we bite the bullet now, and simply add a fully qualified
absolute file name of the dynamic object?