From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27112 invoked by alias); 19 Nov 2010 01:31:20 -0000 Received: (qmail 27104 invoked by uid 22791); 19 Nov 2010 01:31:20 -0000 X-SWARE-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-iw0-f169.google.com (HELO mail-iw0-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Nov 2010 01:31:13 +0000 Received: by iwn38 with SMTP id 38so305228iwn.0 for ; Thu, 18 Nov 2010 17:31:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.31.1 with SMTP id w1mr1598203ibc.7.1290130271423; Thu, 18 Nov 2010 17:31:11 -0800 (PST) Received: by 10.231.172.195 with HTTP; Thu, 18 Nov 2010 17:31:11 -0800 (PST) Date: Fri, 19 Nov 2010 01:31:00 -0000 Message-ID: Subject: Why GDB ignores relative RPATH to find shared libraries? From: Ansis Atteka To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-11/txt/msg00080.txt.bz2 Hello, This is actually a suggestion of how GDB might make easier coredump analysis when RPATH with $ORIGIN is used to specify relative paths to shared libraries. Use case: I have a program which runs on a different machine than it was built on. It uses some system shared libraries (in "/lib" directory) and also some of our own shared libraries (in "/opt/application/lib" directory). The executable itself is in "/opt/application/bin". So path to my libraries is relative with respect to executable (obviously the path to my private libs will be "../lib" from "/opt/application/bin"). The problem is that whenever I need to do remote coredump analysis on development workstation I always have to make sure that GDB uses correct shared libraries. So is there a reason why gdb ignores relative $ORIGIN RPATH and does not automatically load my libs from correct rpath whenever I do "gdb /path/to/executable /path/to/coredump? It seems that GDB favours the paths to shared libraries specified in coredump file instead of those specified in executable and that is not portable for remote analysis. The only case when GDB should favour path to shared libraries from coredump is when executable itself loaded shared library with dlopen(). Other solutions, which I do not like that much: 1. Use relative LD_LIBRARY_PATH=../lib. The problem with this approach is that it sets relative path in respect to Current Working Directory instead of respect to Executable. And of course LD_LIBRARY_PATH leads to other problems... 2. Set *.so lib paths from GDB manually. Extra overhead of work which might lead to other problems. I would prefer that I could simply copy coredump to my build products and do analysis right away without setting any paths explicitly. Best regards, Ansis Atteka