From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21394 invoked by alias); 14 Dec 2014 20:46:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 21384 invoked by uid 89); 14 Dec 2014 20:46:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 14 Dec 2014 20:46:28 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBEKkOrO032137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 14 Dec 2014 15:46:24 -0500 Received: from host2.jankratochvil.net (ovpn-116-142.ams2.redhat.com [10.36.116.142]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBEKkKFc030842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Dec 2014 15:46:23 -0500 Date: Sun, 14 Dec 2014 20:46:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: Eli Zaretskii , gdb-patches Subject: Re: path to find libcc1.so? Message-ID: <20141214204620.GA6990@host2.jankratochvil.net> References: <83mw6sq941.fsf@gnu.org> <20141213185647.GA14208@host2.jankratochvil.net> <20141213201600.GA15686@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00358.txt.bz2 On Sat, 13 Dec 2014 22:49:50 +0100, Doug Evans wrote: > On Sat, Dec 13, 2014 at 12:16 PM, Jan Kratochvil > wrote: > > On Sat, 13 Dec 2014 20:57:35 +0100, Doug Evans wrote: > >> Early adopters and those who want to contribute may find it preferable > >> to use, e.g., ~/.gdbinit. > >> > >> If this is something we eventually want to do, doing it now will help > >> people we want/need. > >> > >> Plus it's, what, 10 lines of (real) code? > > > > It is then questionable whether there should also be a GDB option where to > > find the GCC driver. Currently gcc/libcc1/findcomp.cc searches it in $PATH. > > That is a good question. > > If I configure gcc with a certain --prefix, > and link libcc1.so, with, say, --rpath, > do/should I need to do anything more? > > [for a normal installation (libcc1.so has not been copied out of $prefix and > into some random directory) should libcc1.so be able to find its gcc > on its own?] Currently that libcc1.so will just look at $PATH and find (probably - unless you modify your $PATH) rather your /usr/bin/x86_64-redhat-linux-gcc instead. In some way it is correct. libcc1.so is independent from the GCC driver. libcc1.so just translates API into RPC calls and those RPC calls are received/processed by libcc1plugin.so (loaded due to -fplugin=libcc1plugin passed by libcc1.so to its found gcc driver): /home/jkratoch/redhat/gcchead-root/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/libcc1plugin.so libcc1.so (the RPC calls interface) could be even implemented by GDB itself but for some reason Tom put it at the same source location as the other half (RPC receiver/peer libcc1plugin.so). This is why I proposed think if there should be a GDB option where to locate libcc1.so there could be also a GDB option where to locate the GCC driver, those are technically two mostly independent binaries. One could also have a single GDB option to specify where to locate the GCC driver only. And 'thatpath/gcc -print-file-name=libcc1.so' would really provide the libcc1.so location. Jan