This is the mail archive of the cygwin mailing list for the Cygwin 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: 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:
Problem reports:

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