From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21300 invoked by alias); 1 Jul 2002 17:52:16 -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 21285 invoked from network); 1 Jul 2002 17:52:12 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 1 Jul 2002 17:52:12 -0000 Received: from romulus.sfbay.redhat.com (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g61HrOQ12047; Mon, 1 Jul 2002 10:53:24 -0700 Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g61HqA414610; Mon, 1 Jul 2002 10:52:10 -0700 Date: Mon, 01 Jul 2002 10:52:00 -0000 From: Kevin Buettner Message-Id: <1020701175210.ZM14609@localhost.localdomain> In-Reply-To: Michal Ludvig "cross-target gdb compilation problems" (Jul 1, 6:17pm) References: <3D2080A2.6080702@suse.cz> To: Michal Ludvig , gdb Subject: Re: cross-target gdb compilation problems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-07/txt/msg00013.txt.bz2 On Jul 1, 6:17pm, Michal Ludvig wrote: > When I add '#include "solib.h"' directly to breakpoints.c it compiles > and links just fine. Also it seems like most targets use it anyway. If > we would wrap all #defines in solib.h between #ifndef...#endif it would > remain backward compatible for targets that define their own macros. Or > am I wrong? For targets with shared library support, I think you're right. I think there may be problems, however, on targets without shared library support. (In breakpoint.c, the SOLIB_ADD macro is being used as a flag which indicates that the target has shared library support.) > Like this: > > [solib.h] > + #ifndef SOLIB_ADD > #define SOLIB_ADD(filename, from_tty, targ, readsyms) \ > solib_add (filename, from_tty, targ, readsyms) > + #endif > > Or is there another way to solve my compilation problems? We've had this problem in the past for other pure multiarch targets. I think we ended up creating (or recreating) a tm-*.h file for these targets. Kevin