From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2113 invoked by alias); 3 Oct 2002 15:54:51 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 2094 invoked from network); 3 Oct 2002 15:54:49 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 3 Oct 2002 15:54:49 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g93FZl025887; Thu, 3 Oct 2002 11:35:47 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g93Fsmf07682; Thu, 3 Oct 2002 11:54:48 -0400 Received: from valrhona.uglyboxes.com (IDENT:fdRXeXKxcGiOGlHtcEP8hTew1jOAF2Fs@vpn50-40.rdu.redhat.com [172.16.50.40]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g93Fsk910717; Thu, 3 Oct 2002 11:54:46 -0400 Date: Thu, 03 Oct 2002 08:54:00 -0000 From: Keith Seitz X-X-Sender: keiths@valrhona.uglyboxes.com To: Pierre Muller cc: Andrew Cagney , , Subject: Re: Problem about insight rename patch In-Reply-To: <4.2.0.58.20021003094541.00abd030@ics.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-q4/txt/msg00004.txt.bz2 On Thu, 3 Oct 2002, Pierre Muller wrote: > But that patch also add > _initialize_gdbtk > function reference. Yes, that's true, and if I ever get ten minutes to do this (and I can remember!), I'll submit a patch to fix this. However, it's not quite as critical a bug IMO as long as no one is linking against a libgdb.a built in an insight-enabled build. AFAIK, libgdb.a isn't very useful when insight is enabled (except to insight, of course). > Moreover this means that gtk is still > included in the compilation of gdb executable, > which seem to be the absolute contrary of the aim > of separating gdb and insight, no? [s/gdbtk/gtk/ ?] Yes, this is still true. And if you were to run "gdb -w", insight would show up. Contrary to the purpose of separating the two? Yes, really it is, but we've got to start somewhere. Too often I've found that ideas/patches are rejected because they don't implement everything needed. Some people (not all) are not satisfied by the piecemeal approach: nibble a little here, check it in. Maybe someone else will nibble at it. Eventually, the problem gets solved. Maybe not optimally, but it gets solved. > Basically removing > _initialize_gdbtk from init.c > does not prevent gdb from compiling, > so the only reason why I didn't send a patch proposal > is that I don't know the correct way of fixing it? > Maybe separate init.c > into init.c and insight-init.c? > But there might be better solutions? I believe the proper way to do this (Andrew/others will step in and tell me if I'm barking up the wrong perverbial tree) is to create an init_chain, which holds callbacks to be made for initialization. insight-main.c could register _initialize_gdbtk to this chain and top.c would then call it when it was doing initializations. My initial plan was to submit a patch to do just this. Eventually we could investigate getting other initializations registered in main (or we could simple keep init.c). Or we could just create a new initialize_hook (yich) which main could set to get _initialize_gdbtk to run. Or we could just integrate _initialize_gdbtk into main(), or ... Keith