This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Update to current automake/autoconf/libtool versions.

On Monday, December 30, 2002, at 02:41 PM, Alexandre Oliva wrote:

Sorry I'm a bit late in following up.  I don't follow these lists as
closely as GCC, and this should have been copied there, at least for
the parts that affects the top level, since those are shared.
Yes, my bad: at the time I had hoped to keep the changes contained to the gdb/binutils side of the source tree. I did end up following up with a revised patch to the gcc and newlib mailing lists, though, which is probably a more interesting patch to comment on regardless:

I'm currently preparing a patch to update the gcc directories (boehm-gc fastjar gcc libf2c libffi libjava libobjc libstdc++-v3 zlib) as well, but it'll probably be another day or two before it's ready for posting (the automake conversion is being particularly troublesome). (GNU libtool) 1.4.3
Can't do that.  The copy we use is from a newer code base than the 1.4
branch of libtool.  It's taken from a 1.5-to-be (multi-language)
branch from quite a while ago, back when the ltcf-*.sh scripts hadn't
been merged into libtool.m4.
Yes, I discovered that when I went to update the gcc directories to autoconf-2.57. I've since updated to the current libtool top-of-tree (1.4e-1.1168 2002/12/21), since no currently released libtool supports tagged configurations.

	* .cvsignore: Add autom4te.cache.
Please don't.  autom4te.cache is an aberration.  It shouldn't be
created by default, and it shouldn't be left dangling there in the
source tree.  I'd much rather have rules that remove it as soon as
configure is rebuilt.
I could certainly agree that autom4te.cache is an aberration, but I'm not clear why it's inappropriate to filter it out from the CVS repository. For those who do use it, it's nice to have not showing up in diff and update operations, and for those who don't, the existence of the rule does no harm.

	* acinclude.m4: Remove include of libtool.m4.
Can't let you do that, Dave.  This causes us to use whatever
libtool.m4 happens to be in aclocal.m4's search path, which is very
likely not compatible with from the top level.  That's why
we use libtool.m4 from the top level and keep all the libtool files in
sync.  I wouldn't mind updating to the libtool current CVS tree, which
would get us rid of a number of files in the top level, but this takes
a lot of testing on many different platforms.
Given that in theory anyone running aclocal or autoconf should be running "official" and well-defined versions of those tools, they should also be getting correct values for the contents of libtool.m4. If their installed libtool.m4 is incompatible with the shipped, who is to say that their installed acgeneral.m4 won't be incompatible with a shipped libtool.m4? I'd argue that libtool.m4 is part of the autoconf environment, and that we should just require people running aclocal or autoconf to have the correct installations of the tools (as in theory we already do).

	* Use AC_PROG_LEX instead of AM_PROG_LEX.
	* configure: Pass --build=$host_alias to sub-makes if no other
	value is specified.

Huh?  configure is generated from  Besides, it's wrong
in principle.  --build is not to be the same as --host, it's the other
way round (even though autoconf 2.13 got it backwards).  Gotta find
out why we depend on build being defaulted to host and fixing that
configure is generated automatically now, but it wasn't when I prepared this patch.

If you look at the second patch I prepared (, you'll see that I learned the error of my ways (as defined by, and updated the top-level configure to only pass --build, --host, and --target when explicitly told to by the user (and updated the sub-configures to behave properly in response to that).

This patch is now broken as of the autoconfiscation of the top-level, which unfortunately reverts to the previous behavior of passing --build, --host, and --target down to the sub-configures at all times. I'm working to make a patch for this, but am still caught up on updating the GCC directories to work properly with automake-1.7.2, so it will probably be another day or two.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]