From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14862 invoked by alias); 8 May 2005 22:01:48 -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 14822 invoked by uid 22791); 8 May 2005 22:01:43 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 08 May 2005 22:01:43 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DUtqH-0006Ax-5H for gdb-patches@sources.redhat.com; Sun, 08 May 2005 18:01:41 -0400 Date: Sun, 08 May 2005 22:08:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFC] Unconditionally include shared library code Message-ID: <20050508220141.GA23567@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <200505021251.j42CpxIZ010109@elgar.sibelius.xs4all.nl> <200505081315.j48DF8AG030440@elgar.sibelius.xs4all.nl> <20050508135839.GA7384@nevyn.them.org> <200505081421.j48ELoGI020668@elgar.sibelius.xs4all.nl> <20050508144020.GA8650@nevyn.them.org> <200505081451.j48EpPTO013691@elgar.sibelius.xs4all.nl> <20050508145627.GA9122@nevyn.them.org> <200505082146.j48Lk8TZ022794@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505082146.j48Lk8TZ022794@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00200.txt.bz2 On Sun, May 08, 2005 at 11:46:08PM +0200, Mark Kettenis wrote: > Date: Sun, 8 May 2005 10:56:27 -0400 > From: Daniel Jacobowitz > > On Sun, May 08, 2005 at 04:51:25PM +0200, Mark Kettenis wrote: > > Hmm, that'd work. We'll have to face the inconsistent interface issue > > eventually, but it's a seperate issue indeed. Any objection if I > > introduce a config/tm-solib.h and use that? Its purpose is a bit more > > clear, and the risk of abuse is smaller. The mechanical update is not > > without risk, but I'm willing to take it. Deal? > > I like it. It is indeed a tm file and shouldn't be used any other way. > > I reworked the patch to avoid shlib.[ch]. Looking at the changes I > think the risk of changing solib.h into tm-solib.h under config/ is > riskier than leaving config/ alone and simply removing the #defines > from solib.h. I'm moving towards checking in the attached patch at > the end of the coming week. I like this even more! Kevin? -- Daniel Jacobowitz CodeSourcery, LLC