From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13776 invoked by alias); 10 Jun 2003 00:40:39 -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 13617 invoked from network); 10 Jun 2003 00:40:38 -0000 Received: from unknown (HELO ms-smtp-03.nyroc.rr.com) (24.92.226.153) by sources.redhat.com with SMTP; 10 Jun 2003 00:40:38 -0000 Received: from doctormoo (syr-24-24-16-157.twcny.rr.com [24.24.16.157]) by ms-smtp-03.nyroc.rr.com (8.12.5/8.12.2) with ESMTP id h5A0eaik021901; Mon, 9 Jun 2003 20:40:37 -0400 (EDT) Received: from neroden by doctormoo with local (Exim 3.36 #1 (Debian)) id 19PXBa-00083J-00; Mon, 09 Jun 2003 20:40:26 -0400 Date: Tue, 10 Jun 2003 00:40:00 -0000 To: gcc@gcc.gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com, aoliva@redhat.com Subject: Re: Partial autoconf transition thoughts Message-ID: <20030610004025.GA26915@doctormoo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i From: Nathanael Nerode X-SW-Source: 2003-06/txt/msg00135.txt.bz2 Alexandre Oliva said: >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 Whaaaat? This seems like a rather dumb idea with no serious benefit. -- Let's look at this another way. What are the *differences* between a build=host compilation and a build!=host compilation? 1. Certain tools used while building have different names. I have effectively isolated this issue into macros in config/acx.m4. They can be improved if necessary, but they're already quite clever. More importantly, *we* have control over these and can make them decide based on *our* choice of when it's appropriate. 2. Testing can be done on the build machine. Not a configuration issue! 3. Certain headers are to be found in a different place. This is a legitimate difference, which might induce a desire for 'cross-building' when build=host, but it can be specified explicitly in other ways already, I believe. 4. Certain libraries are found in different places. In the case of static linking, this is the same as the above. In the case of dynamic linking, this should be manually overridable (and it seems to be moderately hit-and-miss in the cross case anyway, given inconsistent dynamic library naming and locating schemes). I can think of no other differences. I proceed on the principle that there are no real, fundamental differences between a native configuration and a cross configuration, and this generally creates the cleanest configury code. >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. Absolutely. We're already passing a complete set down to the 'target' directories and to the 'build' directories. I think we should also pass a complete set down to the 'host' directories, and they should be bright enough to understand that if build=host, build=host. (Regardless of what some autoconf people may be advocating.) --Nathanael