[ITP] gcc-tools-autoconf, gcc-tools-automake

Yaakov (Cygwin/X) yselkowitz@users.sourceforge.net
Mon Jan 5 07:27:00 GMT 2009

Hash: SHA256

Charles Wilson wrote:
> Yes, because gcc requires the use of an unmodified automake. Our
> existing 1.9.6 package is modified [*] -- and you can't have two
> versions of the same minor automake release installed at the same time
> in the same prefix.

In what way does gcc "require" a vanilla automake?  Below you say that
the only difference is some libobj fixes.  To me that means that gcc
will build, but the patches won't be quite right (meaning that gcc keeps
Makefile.in in CVS?).  That's not exactly what I call "requiring".

> Perhaps we could drop the libobj support from our am-1.9 packages? Sure,
> but then IIRC cygwin libtool (1.5 only? also 2.2? Can't recall.) will
> fail some of its regression tests -- with possible real-world
> consequences for packages other than gcc/binutils.

It would be good to know if the automake patches are no longer needed
with libtool-2.2, but for now let's assume the worst.

> [**] I'm cheating a bit with regards to libtool, as I haven't made a
> gcc-tools-libtool package. But that's because I think it is probably not
> necessary for Dave et. al. to try to update the libtool stuff in the gcc
> tree; it's already at git-master post-2.2.6-release; Ralf W. has been
> keeping it reasonably up to date; and you don't use libtoolize to do it,
> anyway. You manually copy the relevant m4 files -- sadly, libtoolize
> makes a hash of the src/ tree. At least it did the last time I tried to
> do it that way.

Our libtool is basicall vanilla anyway; the LT_OUTPUT patch (which
anyways I'm not sure that we need anymore) wouldn't be relevant here.

Dave, if you could please send me your .src.patch(es), then I'll be
happy to take a look at this.


Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Cygwin-apps mailing list