From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21968 invoked by alias); 31 Oct 2004 19:45:31 -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 21961 invoked from network); 31 Oct 2004 19:45:30 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 31 Oct 2004 19:45:30 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id i9VJjN6Y001066; Sun, 31 Oct 2004 20:45:23 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id i9VJjMSq002669; Sun, 31 Oct 2004 20:45:22 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id i9VJjMoG002666; Sun, 31 Oct 2004 20:45:22 +0100 (CET) Date: Sun, 31 Oct 2004 19:45:00 -0000 Message-Id: <200410311945.i9VJjMoG002666@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: cagney@gnu.org CC: drow@false.org, gdb-patches@sources.redhat.com In-reply-to: <4185314C.7020307@gnu.org> (message from Andrew Cagney on Sun, 31 Oct 2004 13:39:08 -0500) Subject: Re: [COMMIT] OpenBSD/mips64 target and native support References: <200410231216.i9NCG6YK023827@elgar.sibelius.xs4all.nl> <417D1A69.2070904@gnu.org> <20041025152912.GA28110@nevyn.them.org> <417D4D56.80003@gnu.org> <4185314C.7020307@gnu.org> X-SW-Source: 2004-10/txt/msg00551.txt.bz2 Date: Sun, 31 Oct 2004 13:39:08 -0500 From: Andrew Cagney >>> This part: >>> >>> >>>> +DEPRECATED_TM_FILE= tm-nbsd.h >>> >>> >>> is no longer acceptable. The situtation we have here is identical to that we encountered when we first made it a requirement that not just new architectures, but also extensions to exsting architectures, had to be multi-arch. We set the standard and then helped developers exceed it. Our only mistake was to "blink" when it came to the solib problem. We've been "blinking" for too many years now. So should I just commit the attached to get things moving? IMHO, getting the solib h thingy fixed simply isn't top priority. There are more important issues in GDB that deserve my attention. Scaring away contributors by making unreasonable demands isn't a sensible thing to do. Mark Index: ChangeLog from Mark Kettenis * config/i386/linux.mt (DEPRECATED_TM_FILE): Remove. Index: config/i386/linux.mt =================================================================== RCS file: /cvs/src/src/gdb/config/i386/linux.mt,v retrieving revision 1.10 diff -u -p -r1.10 linux.mt --- config/i386/linux.mt 13 Sep 2004 20:55:39 -0000 1.10 +++ config/i386/linux.mt 31 Oct 2004 19:21:53 -0000 @@ -1,4 +1,3 @@ # Target: Intel 386 running GNU/Linux TDEPFILES= i386-tdep.o i386-linux-tdep.o glibc-tdep.o i387-tdep.o \ solib.o solib-svr4.o symfile-mem.o -DEPRECATED_TM_FILE= tm-linux.h