From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20129 invoked by alias); 9 Apr 2002 13:28:23 -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 20113 invoked from network); 9 Apr 2002 13:28:22 -0000 Received: from unknown (HELO delorie.com) (207.22.48.162) by sources.redhat.com with SMTP; 9 Apr 2002 13:28:22 -0000 Received: from envy.delorie.com (envy.delorie.com [207.22.48.171]) by delorie.com (8.11.6/8.9.1) with ESMTP id g39DSJf03553; Tue, 9 Apr 2002 09:28:19 -0400 Received: (from dj@localhost) by envy.delorie.com (8.11.6/8.11.2) id g39DSJF21858; Tue, 9 Apr 2002 09:28:19 -0400 Date: Tue, 09 Apr 2002 06:28:00 -0000 Message-Id: <200204091328.g39DSJF21858@envy.delorie.com> X-Authentication-Warning: envy.delorie.com: dj set sender to dj@delorie.com using -f From: DJ Delorie To: schwab@suse.de CC: gcc@gcc.gnu.org, binutils@sources.redhat.com, gdb@sources.redhat.com In-reply-to: (message from Andreas Schwab on Tue, 09 Apr 2002 10:55:00 +0200) Subject: Re: Overlapping patterns in toplevel configure.in References: X-SW-Source: 2002-04/txt/msg00125.txt.bz2 > The toplevel congfigure.in script contains a case pattern *-*-linux* that > overrules the pattern mips*-*-linux*. The first pattern only exists in > the gcc repository, not in the src repository. There are also other linux > cases that are not a superset of the generic *-*-linux* case. What is the > best way to resolve that? Perhaps the generic linux pattern should be > moved to a separate case statement. But there is also a catch-all > pattern at the end that disables libgcj for all not explicitly mentioned > targets unless --enable-libgcj is given. In other words, it's a big > mess. :-( I'm currently working on syncing the toplevel files between gcc and src, so at least please wait until I finish that, or at least make sure both sides get updated. Otherwise, simply rearranging the patterns so that the more specific ones come first makes sense; perhaps put all the chip-independent patterns at the end?