Patch to update libtool in GCC and Src trees
Fri May 18 01:40:00 GMT 2007

[adding the lists back]

On Thu, 17 May 2007 14:03:34 -0700 (PDT), "Steve Ellcey"

> Chuck, I am confused by your inclusion of 'compile' in the package.
> Looking at my trees, I already see compile in the top-level of the GCC
> and src tree's and it is the same version that you sent me.

Well, that's really odd.  My src checkout didn't contain it, but looking
at viewCVS (src tree) and viewSVN (gcc tree) I see that, as you say, it
is there and it is the same version.  I wonder if it is a module
definition thing: if you do a checkout winsup or checkout newlib, maybe
you don't get all the files in toplevel?

Hmm, it appears that the module definitions are going to need updating
as part of your patch:

If you check out the entire src/ tree, you get all the contents of
<toplevel>, including compile.  OTOH, if you check out any explicit
module (binutils, or newlib, or winsup) like I did, they all rely on the
src-support module to get the necessary toplevel crud.

But: the src-support module definition does NOT contain compile!

Hence, I was missing compile, and thought it needed to be added.  But
what's really happened is that we've discovered a bug in the src tree:
the module definition for src-support needs to list 'compile'.  

With your patch, it will also need to list ltversion.m4, ltoptions.m4,
and ltsugar.m4.

Module definitions are not versioned.  It seems to me that the module
definition should list ALL possible files that EVER were part of the
module; if they've been deleted or were never added for your particular
branch you just won't see them on checkout.  Evidence for this: the
'src-support' module currently includes both "<toplevel>"
and "<toplevel>" -- but only one exists in any given branch.

I don't know how SVN deals with modules, if it even supports them, or
whether the gcc tree exhibits any problem similar to that observed here
in the src tree.


More information about the Newlib mailing list