This is the mail archive of the
mailing list for the Cygwin project.
Re: autoconf/automake problem: simple testcase [was RE: autoconf/automake: just can't get it to work at all.]
Thanks for helping David, Brian. Your answers are almost entirely
correct. David, here's the current status:
(1) autoconf now uses the same wrapper that is shipped by Mandr* & Red
Hat (and others, I think) instead of my crappy home grown one. So
you've got a wrapper package ('autoconf'), and two versions of the
actual tool ('autoconf2.5' and 'autoconf2.1'). There are no more
"devel" and "stable". You can either rely on the wrapper to DTRT, or
explicitly call autoconf2.5 or autoconf2.1. Also, the WANT* stuff does
indeed have an effect. Obviously, both of these versions coexist.
(2) automake has no wrappers anymore. You just either call the desired
version explicitly ('automake1.7', 'aclocal1.9') or rely on the
'alternatives' system to give you the most recent or sysadmin-selected
version by creating a symlink for 'automake'. All of these versions
coexist. (Also, the maintainer-mode rules created by automake already
DTRT: they explicitly call the version of aclocal/automake that they want).
(3) There is only one libtool -- version 1.5.20. I have not yet
attempted to come up with a scheme where you can *smoothly* have
multiple versions of libtool installed simultaneously. Caveat User.
In fact, our current system is practically identical to the way Mandr*
and Red Hat install the autotools. Which means....
You'd have EXACTLY these same issue if you were building binutils in
maintainer-mode on a Linux box, as Brian explains below:
Brian Dessent wrote:
From that you can see that the problem is that bfd/, gas/, gprof/,
libiberty/, and opcodes/ all use automake 1.9 / autoconf 2.59; whereas
the toplevel and binutils/ use automake 1.4 / autoconf 2.13. It seems
like no matter what incantation of WANT_AUTOCONF_2_1 and
update-alternatives that you use, something will be unhappy as a result.
Yes. Same thing goes with gcc & friends. There is, I believe, some
slow progress towards modernizing and canonicalizing the autotools used
to build gcc (and maybe binutils), but I'm not sure what the current
status of that effort is. In the bad old days, gcc used a bastardized
and hacked version of libtool1.4 which was REALLY awful...I think
*that*, at least, has been corrected, and individual subdirectories
within these two projects are being switched over to ac-2.5x and
am-newer, on a one-subdir-at-a-time basis).
So it looks like a better way to go is to just run "autoreconf" in the
subdirs that you want to regenerate, rather than configuring at the top
level with --enable-maintainer-mode.
Unfortunately, it's not that simple -- if it were, Zack and Nathanael
and the other contributors would not have had to work so hard to make
the progress they have, in updating the autotooling of gcc/binutils.
(And, we'd probably already have a shared libstdc++ runtimelib by now).
I do not believe the "real" maintainers of either gcc or binutils use
the maintainer-mode rules at all; those rules are only there because
automake puts them there. Neither baseline is yet in shape to truly
exploit those rules -- which assume the same version of all autotools
thru-out a given project. This is not true for binutils or gcc, as
Brian points out.
Thus, any updates of the autotooling in those projects is done by
explicitly calling the [correct version of the] autotools within a
specific subdirectory. At least, that's my understanding.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html