X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_82,J_CHICKENPOX_84,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: <4A86C42E.4060503@cwilson.fastmail.fm> Date: Sat, 15 Aug 2009 10:20:30 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Cygwin Mailing List Subject: gcc-tools versions of autotools [Fwd: Moving to Autoconf 2.64, Automake 1.11] Content-Type: multipart/mixed; boundary="------------090602070801040802040108" Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com --------------090602070801040802040108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit (Mostly for Dave Korn, but other opinions solicited): How do you want me to handle updating gcc-tools-autoconf and gcc-tools-automake? My preference would be to /not/ update them at all; at least, not for a while. Reasons: 1) The current and soon-to-be-released gcc's, based on gcc-3.4.5 and gcc-4.3.x, both still require autoconf-2.59 and automake-1.9.6 [actually, I'm not sure about that; gcc-3.x might still be stuck in ac-2.13 land]. 2) The only reason we needed separate versions of these autotools rather than using the cygwin standard ones was because the cygwin standard versions have been modified from the pristine upstream editions. This means that patches including regenned files would be unacceptable upstream. However, the cygwin standard version of automake-1.11 has no substantantive patches -- only automake.texi. Ditto autoconf-2.63 -- only autoconf.texi and autoconf.el. I have no doubt that autoconf-2.64 will also need no cygwin-specific modifications. So, as soon as I spin the "regular" cygwin autoconf-2.64 package, then our "standard" auto* installations will satisfy gcc's needs; all you'd need to do is /stop/ setting PATH to prepend /opt/gcc-tools/bin. ...until automake-1.11.1 or autoconf-2.65 is released. Then we get to worry about it more. I've a few ideas about that, but for later...unless you want to handle the transition /now/ for gcc-tools-*. Side question: has anybody checked to see if src/winsup can handle autoconf-2.64 and automake-1.11? -- Chuck --------------090602070801040802040108 Content-Type: message/rfc822; name="Moving to Autoconf 2.64, Automake 1.11.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Moving to Autoconf 2.64, Automake 1.11.eml" Path: news.gmane.org!not-for-mail From: Ralf Wildenhues Newsgroups: gmane.comp.gnu.binutils Subject: Moving to Autoconf 2.64, Automake 1.11 Date: Sat, 15 Aug 2009 13:29:28 +0200 Approved: news AT gmane DOT org Message-ID: <20090815112928.GB5396__17070.0376075276$1250335815$gmane$org AT gmx DOT de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1250335815 24866 80.91.229.12 (15 Aug 2009 11:30:15 GMT) X-Complaints-To: usenet AT ger DOT gmane DOT org NNTP-Posting-Date: Sat, 15 Aug 2009 11:30:15 +0000 (UTC) To: gcc-patches AT gcc DOT gnu DOT org, binutils AT sourceware DOT org, gdb AT sourceware DOT org Original-X-From: binutils-return-60939-gcgb-binutils=m DOT gmane DOT org AT sourceware DOT org Sat Aug 15 13:30:08 2009 Envelope-to: gcgb-binutils AT gmane DOT org Original-Received: from sourceware.org ([209.132.176.174]) by lo.gmane.org with smtp (Exim 4.50) id 1McHSZ-0005ZX-Pl for gcgb-binutils AT gmane DOT org; Sat, 15 Aug 2009 13:30:08 +0200 Original-Received: (qmail 29889 invoked by alias); 15 Aug 2009 11:29:43 -0000 Original-Received: (qmail 29811 invoked by uid 22791); 15 Aug 2009 11:29:41 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Original-Received: from mail.gmx.net (HELO mail.gmx.net) (213.165.64.20) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Sat, 15 Aug 2009 11:29:33 +0000 Original-Received: (qmail invoked by alias); 15 Aug 2009 11:29:29 -0000 Original-Received: from xdsl-87-78-133-82.netcologne.de (EHLO localhost.localdomain) [87.78.133.82] by mail.gmx.net (mp056) with SMTP; 15 Aug 2009 13:29:29 +0200 Original-Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1McHRw-0005FJ-Ga; Sat, 15 Aug 2009 13:29:28 +0200 Mail-Followup-To: Ralf Wildenhues , gcc-patches AT gcc DOT gnu DOT org, binutils AT sourceware DOT org, gdb AT sourceware DOT org Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-08-09) X-IsSubscribed: yes Mailing-List: contact binutils-help AT sourceware DOT org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: binutils-owner AT sourceware DOT org Delivered-To: mailing list binutils AT sourceware DOT org Xref: news.gmane.org gmane.comp.gnu.binutils:42947 Archived-At: Hello everyone, I will reply to this message with a number of patches that contain the heart of the switch to newer autotools. They apply in the order posted, and each successive version is expected to work, or at least only break minor bits such as provoking an automake warning about duplicate install-pdf, but my plan is to get them all approved and then apply them in short succession. (Splitting them by topic is really helpful to maintain sanity, and be able to distinguish generated from manual changes.) For committing the series, would it be ok to then ask for a couple of hours in which no changes to the build system are made? - Update automake-provided helper scripts in the toplevel, - LIBTOOLFLAGS, and *_LINK fixes for Automake 1.11 (GCC only), - some minor fixes in sim, gold, gdb (src only) - Bump Autoconf version to 2.64 in override.m4, and regenerate the world with 2.64 and Automake 1.11, - remove {all,install}-{html,pdf} and {dataroot,doc,pdf,html}dir stuff not needed any more, update documentation bits throughout the tree. Apart from that, I would need somebody to update the autotools tarballs at ftp://sources.redhat.com/pub/binutils for me, at the time I am committing the above. The upstream tarballs are available here: ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.64.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.11.tar.gz I have done a bunch of testing of the resulting trees, mostly native bootstraps+regtests however (no regressions). I think I have addressed all issues that cropped up and that have been documented before on this list. Notably, however, I have not done a --with-build-sysroot test; I would like to ask someone else to do this for me. I do have good reason to believe that the issue reportd in is fixed in my patch series, though: the very likely reason for the above was that the *_LDFLAGS/*_LINK semantic change was not addressed. The texinfo changes have been tested with 'make info pdf html'. To make it easy for whoever volunteers for the --with-build-sysroot test, I would like to ask for this to be done after I commit the patch set. OK? Note that I do expect one or two more things that could break some specific build setups; I don't think it is feasible to test them all in advance, but I will try to look at them in a short order then. This patch series can be extended with two more helpful changes that are not time-critical: - bump all the AC_PREREQ's to 2.64, add 1.11 to AUTOMAKE_OPTIONS or AM_INIT_AUTOMAKE calls as requirement, to avoid accidental use of old tools. The config/override.m4 bit ought to prevent the error for Autoconf already, unless other weird issues come into play, too, such as also inadvertently dropping some aclocal -I ../config options or so. (My thinking here was that, as some parts of the tree are shared with external projects, they don't need to upgrade their autotools usage right at the same time.) - fix the (new with Autoconf 2.64) warnings from configure about unknown --enable/--with switches. I would appreciate some input on whether this functionality should just be turned off with AC_DISABLE_OPTION_CHECKING, or we should add some logic to the toplevel configure script to be more intelligent about it. Thanks for all the review work done so far! Ralf --------------090602070801040802040108 Content-Type: text/plain; charset=us-ascii -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple --------------090602070801040802040108--