From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10679 invoked by alias); 21 Feb 2003 19:42:44 -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 10661 invoked from network); 21 Feb 2003 19:42:44 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 21 Feb 2003 19:42:44 -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 h1LJghN14293 for ; Fri, 21 Feb 2003 14:42:43 -0500 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 h1LJghf09523; Fri, 21 Feb 2003 14:42:43 -0500 Received: from localhost.localdomain (vpn50-17.rdu.redhat.com [172.16.50.17]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1LJggt02344; Fri, 21 Feb 2003 14:42:42 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h1LJJFk15927; Fri, 21 Feb 2003 12:19:15 -0700 Date: Fri, 21 Feb 2003 19:42:00 -0000 From: Kevin Buettner Message-Id: <1030221191915.ZM15926@localhost.localdomain> In-Reply-To: "Kris Warkentin" "[Proposal] GDB honouring RPATH in binaries." (Feb 21, 1:30pm) References: <0db801c2d914$78f80a50$0202040a@catdog> <1030220193301.ZM10611@localhost.localdomain> <20030220194049.GA19653@nevyn.them.org> <001301c2d918$894ef1d0$0202040a@catdog> <20030220194852.GA20424@nevyn.them.org> <002701c2d919$d07edce0$0202040a@catdog> <1030220195833.ZM10783@localhost.localdomain> <15957.17196.501000.893848@gargle.gargle.HOWL> <20030220201032.GA21694@nevyn.them.org> <00e001c2d9be$616ca940$0202040a@catdog> <023401c2d9d7$5441ce30$0202040a@catdog> To: "Kris Warkentin" , "Daniel Jacobowitz" , "Paul Koning" Subject: Re: [Proposal] GDB honouring RPATH in binaries. Cc: , , "Colin Burgess" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00479.txt.bz2 On Feb 21, 1:30pm, Kris Warkentin wrote: > > Aha. Looks like our loader just fills in the basename of the lib it > finds. > > That explains why we need so much initialization of solib-search-path and > so > > on. I'm going to get our kernel guy to change that so that we can just > use > > solib-absolute-prefix. > > This doesn't work for us. The situation is that there might be no clear > link between the host and target directory structures. In general, all our > libs wind up in /proc/boot on the target image so when the loader fills in > 'libc.so' rather than '/proc/boot/libc.so', it's a benefit since we can use > solib-search-path to find $QNX_TARGET/$CPU/lib/libc.so, regardless of host. I still find myself confused as to why your loader only wants to fill in the basename. Having an absolute path won't preclude using solib-search-path. And it will certainly make things easier when you have an accurate target image residing (somewhere) on the host so that you can use solib-absolute-prefix. > So, we're stuck with initializing solib-search-path. The problem with this > is that if the user needs another path in there (as in the RPATH situation), > he has no way of appending to solib-search-path. It's either set or show. > This makes for ugly cut and paste and general unfriendlyness. > > So, I have two potential solutions: > > One: We could add something like 'vendor-solib-search-path' which could be > searched so that solib-search-path can be left for the user. Then vendors > can just initialize v-s-s-p and users don't have to worry. I'm not in favor of this. > Two: provide a mechanism to append strings to gdb variables such as > solib-search-path which might be useful in other situations. A really nice > implementation would be some form of variable expansion, ie: > > set solib-search-path $solib-search-path:/home/foo I think something like this has been discussed before. It sounds like a good idea to me. Kevin