From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27299 invoked by alias); 5 Dec 2002 20:55:40 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27282 invoked from network); 5 Dec 2002 20:55:39 -0000 Received: from unknown (HELO dc-mx11.cluster1.charter.net) (209.225.8.21) by sources.redhat.com with SMTP; 5 Dec 2002 20:55:39 -0000 Received: from [66.189.46.2] (HELO platinum.local.) by dc-mx11.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with ESMTP id 8066457; Thu, 05 Dec 2002 15:55:38 -0500 Date: Thu, 05 Dec 2002 12:55:00 -0000 Subject: Re: [RFC] Update to current automake/autoconf/libtool versions. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: binutils@sources.redhat.com, gdb-patches@sources.redhat.com To: Andrew Cagney From: Klee Dienes In-Reply-To: <3DEF8642.70405@redhat.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00179.txt.bz2 On Thursday, December 5, 2002, at 12:00 PM, Andrew Cagney wrote: >> On Thursday, December 5, 2002, at 10:43 AM, Andrew Cagney wrote: >>> I don't understand this: >>> - $(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/c-exp.y y.tab.c c-exp.tmp >>> -- $(YFLAGS) >>> + $(SHELL) $(YLWRAP) $(srcdir)/c-exp.y y.tab.c c-exp.tmp -- >>> "$(YACC)" $(YFLAGS) >>> isn't it independant of the switch? >>> >> It's a result of using the ylwrap from autoconf-1.7, which is needed >> since the rules for the binutils/ parsers are automatically generated >> by automake. >> > Does it work now? I'm not sure I understand the question, but I'll elaborate on the situation a bit in hopes that I can answer it anyway. Automake-1.4p5 generates Makefile.in's that use the syntax: ylwrap PROGRAM INPUT [OUTPUT DESIRED]... -- [ARGS]... Automake-1.7 generates Makefile.in's that use the syntax: ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]... So if we use automake-1.7 to build Makefile.in binutils/ld/gas, we need to use the ylwrap from automake-1.7 as well, which uses the new syntax and therefore requires the change to the GDB Makefile.in. I don't think it's possible to have a version of the GDB Makefile.in that works with both versions. >>> Same with this? >>> - AC_DEFINE(HAVE_LONG_DOUBLE) >>> + AC_DEFINE([HAVE_LONG_DOUBLE], [], [Define if the `long double' >>> type works]) >>> (or did the new autoconf change the interface causing a warning if >>> the three parameters were not present?). > >> Not even a warning: it blows out autoheader with an error. The new >> AC_DEFINE interface deprecates the use of a template file, and >> instead requires all the information to be provided by the AC_DEFINE >> commands (it's particularly annoying since the warning about the >> existence of a template file is about 10 lines long, ALL CAPS, and >> can't be turned off with --warnings=none). > > Ulgh. Same here though, does this work with autoconf 2.13++ (the > current offical autoconf)? The 3-argument form works with both autoconf-2.13 and autoconf-2.50+. Is autoconf-2.13 really the current official autoconf? The autoconf release announcements don't make that at all clear: > - Why should I upgrade from 2.13? > > This version is no longer maintained. It does not address recent > architectures, recent compilers etc. We know that upgrading from 2.13 > to 2.5x is not an easy task, especially because the Autoconf 2.13 was > extremely tolerant of incorrect macro invocations, but waiting longer > endangers the portability of your package and only delays the > conversion to newer Autoconf versions. Worse: some maintainers now > spend a significant amount of time fixing bugs in 2.13 or backporting > macros from 2.55. Or do you mean that autoconf-2.13++ is the current official version for Binutils/BFD (in which case I withdraw my question)?