From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1007 invoked by alias); 9 Jun 2003 23:14:45 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 982 invoked from network); 9 Jun 2003 23:14:44 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 9 Jun 2003 23:14:44 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19PVrJ-00018B-00; Mon, 09 Jun 2003 18:15:26 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19PVqS-0005KA-00; Mon, 09 Jun 2003 19:14:32 -0400 Date: Mon, 09 Jun 2003 23:14:00 -0000 From: Daniel Jacobowitz To: Alexandre Oliva Cc: gcc@gcc.gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: Partial autoconf transition thoughts Message-ID: <20030609231432.GA12928@nevyn.them.org> Mail-Followup-To: Alexandre Oliva , gcc@gcc.gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com References: <20030609220248.GA21303@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00130.txt.bz2 On Mon, Jun 09, 2003 at 07:34:00PM -0300, Alexandre Oliva wrote: > On Jun 9, 2003, Daniel Jacobowitz wrote: > > > 4. Specify the same thing for both > > 2.13: Both will be overridden; test $CC for cross mode. > > 2.57: Both will be overridden, will build natively. > > Except that building natively is deprecated, and autoconf people have > already pushed for removing this alternative. We probably don't want > to rely on it, unless the entire transition is going to be *very* > short, and I don't think it can possibly be, since we're not going to > have simultaneous releases of all of gcc, binutils, gdb and newlib, > such that one could take all of them after the conversion and build a > unified tree. As I told Alex on IRC, I was looking at the upgrading-from-2.13 section of the manual (where it isn't clear that this is deprecated) and the generated configures (where it obviously works). My instinct is to rely upon this deprecated feature of 2.57 as it is easy to remove once we have transitioned all directories, which I expect to be fairly quick. > > So I guess I don't see what the problem is with doing one directory at a > > time. > > There are also libtool issues. We want to use a single libtool.m4, > and you say our current libtool.m4 doesn't work with autoconf 2.5x > (did I misunderstand?), and this was a problem I didn't know about > before. Nope, pilot error on my part. It works fine here. I even did both autoconf and automake in the gas directory. > > There are existence proofs that this (mostly!) works - > > readline has been using autoconf 2.57 since its last import. > > I've heard people complain it was being configured as if for cross > compilation even on native builds. Has never happened to me. > > Could someone who thinks this won't work please speak up, before I > > waste a lot of time? > > It should mostly work, but I still think we should pass different > arguments to sub-configures depending on which version of autoconf was > used to configure them. I understand that, and how to do it. But _what_ different arguments do you want? What's the mapping? When I sat down to work out the mapping I produced my original table and decided I didn't need a mapping at all. > > I tested a native build on i386-linux > > What configure arguments? Did you pass i386-linux in the command > line? Maybe one of --build or --host? The worst case to handle IMO > is that of passing --build, since then autoconf 2.13 directories will > guess --host from config.guess, whereas autoconf 2.57 will default > host to build. If they're different, we get an inconsistent build > across directories. That's why I think we should resolve the flags in > the top level, and decide what to pass to each sub-directory. I jut retried these: --build=i686-linux --host=i686-linux --build=i686-linux --host=i686-linux i686-linux All five worked fine. Perhaps I'll do libiberty next. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer