autoconf/automake problem: simple testcase [was RE: autoconf/automake: just can't get it to work at all.]

[Charles Wilson]

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.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/