From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31005 invoked by alias); 25 Feb 2006 01:45:11 -0000 Received: (qmail 30989 invoked by uid 22791); 25 Feb 2006 01:45:10 -0000 X-Spam-Check-By: sourceware.org Received: from dsl027-180-168.sfo1.dsl.speakeasy.net (HELO sunset.davemloft.net) (216.27.180.168) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 25 Feb 2006 01:45:09 +0000 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.60) (envelope-from ) id 1FCoUo-0005Ho-J6; Fri, 24 Feb 2006 17:45:18 -0800 Date: Sat, 25 Feb 2006 01:45:00 -0000 Message-Id: <20060224.174518.102972954.davem@davemloft.net> To: roland@redhat.com Cc: libc-hacker@sources.redhat.com Subject: Re: [PATCH]: Missing Sparc Implies From: "David S. Miller" In-Reply-To: <20060225014143.62DA3180A66@magilla.sf.frob.com> References: <20060224.172413.37789507.davem@davemloft.net> <20060225014143.62DA3180A66@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00040.txt.bz2 From: Roland McGrath Date: Fri, 24 Feb 2006 17:41:43 -0800 (PST) > > From: Roland McGrath > > Date: Fri, 24 Feb 2006 16:47:08 -0800 (PST) > > > > > I don't think ought to be necessary. If it is, I'd like to fix the > > > configure magic so it's not. Those Implies files from the main source > > > should cause those add-on directories to be searched too. > > > > This doesn't happen in the top-level either, that's why we need > > sysdeps/unix/sysv/linux/sparc/sparc32/sparcv9b/Implies and friends > > eventhough we have sysdeps/sparc/sparc32/sparcv9b/Implies. > > I'm not following you. The main tree tree has > sysdeps/unix/sysv/linux/sparc/sparc32/sparcv9b/Implies already. > Another one should not be required in the add-on too. > The one would not be required either if we used sparcv9/sparcv9b instead. I guess I don't understand how the "machine=" specification in the configure scripts work... They look like file path names that the build machinery tries one by one like this: machine=a/b/c/d step 1) try $(foo)/a/b/c/d step 2) try $(foo)/a/b/c step 3) try $(foo)/a/b step 4) try $(foo)/a You seem to be suggesting that it works another way.