RE: autoconf/automake problem: simple testcase [was RE: autoconf/automake: just can't get it to work at all.]
Gary R. Van Sickle wrote: From: Dave Korn [snip] I don't get that. I've got the default alternatives set, so IIUIC it should have selected the most recent autoconf, shouldn't it? I imagine this is intended to work with everything in the default installation state, but as you see it certainly doesn't WFM! You use text mounts? ackSPIT Nope. :) cheers, DaveK -- Can't think of a witty .sigline today -- 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/
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.
--
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/
RE: autoconf/automake problem: simple testcase [was RE: autoconf/automake: just can't get it to work at all.]
From: Dave Korn [snip] I don't get that. I've got the default alternatives set, so IIUIC it should have selected the most recent autoconf, shouldn't it? I imagine this is intended to work with everything in the default installation state, but as you see it certainly doesn't WFM! You use text mounts? The alternatives package was(is?) busted, and only worked if /var/lib/alternatives is binmode. If this is it, IIRC correctly the files therein will have to be manually d2u'ed and/or otherwise fixed up. -- Gary R. Van Sickle -- 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/
Re: autoconf/automake problem: simple testcase [was RE: autoconf/automake: just can't get it to work at all.]
Dave Korn wrote: Umm, it definitely *does* have an effect; see the differences it made to the examples I posted in the previous case. Is it possible I have some remnants of the old autoconf stuff lying around? I updated this morning and didn't see any problems, and nor does cygcheck report any, and a quick browse through /usr/share/autotools/ac-wrapper.pl shows it clearly tests and responds to WANT_ and FORCE_ env vars. Right but that's autoconf which still has the version-sniffing-wrapper stuff. Automake doesn't have any of that and relies entirely on /etc/alternatives. It doesn't work OOTB. Here's a simple testcase: on my system, which is up-to-date as of this morning, and on which I've never ever run alternatives to change any settings, you can't build current binutils when you configure with --enable-maintainer-mode. If binutils expects automake 1.4 then I wouldn't expect it to work OOTB since the default alternative that the postinstall sets up is 1.9. What does update-alternatives --display automake say? --snip #!/bin/bash cd /tmp rm -rf autotooltest mkdir autotooltest cd autotooltest wget 'http://ftp.gnu.org/gnu/binutils/binutils-2.16.1.tar.bz2' tar xjf binutils-2.16.1.tar.bz2 mkdir obj cd obj /tmp/autotooltest/binutils-2.16.1/configure -v --enable-maintainer-mode 21 | tee conf.log make all 21 | tee build.log --snip ... make[1]: Entering directory `/tmp/autotooltest/obj/binutils' cd /tmp/autotooltest/binutils-2.16.1/binutils aclocal-1.4 cd /tmp/autotooltest/binutils-2.16.1/binutils automake-1.4 --cygnus Makefile cd /tmp/autotooltest/binutils-2.16.1/binutils autoconf FATAL ERROR: Autoconf version 2.50 or higher is required for this script make[1]: *** [/tmp/autotooltest/binutils-2.16.1/binutils/configure] Error 2 make[1]: Leaving directory `/tmp/autotooltest/obj/binutils' make: *** [all-binutils] Error 2 Try this on the unmodified upstream tarball: $ find . -name \*.in -o -name \*.am -o -name \*.m4 -o -name configure \ | xargs grep -iP -m1 generated (automatically )?(by|using) 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. 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. Brian -- 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/
