From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25908 invoked by alias); 15 Jan 2012 18:51:57 -0000 Received: (qmail 25881 invoked by uid 22791); 15 Jan 2012 18:51:55 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 15 Jan 2012 18:51:40 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LXU00100SBX1Z00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Sun, 15 Jan 2012 20:51:14 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.65.106]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LXU0006JSDD45J0@a-mtaout22.012.net.il>; Sun, 15 Jan 2012 20:51:14 +0200 (IST) Date: Sun, 15 Jan 2012 18:55:00 -0000 From: Eli Zaretskii Subject: Re: Building GDB 7.3.92 with MinGW In-reply-to: <20120115133427.GW31383@adacore.com> To: Joel Brobecker Cc: pierre.muller@ics-cnrs.unistra.fr, asmwarrior@gmail.com, dje@google.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83pqekiytx.fsf@gnu.org> References: <20120112064721.GN31383@adacore.com> <20120112115355.GO31383@adacore.com> <838vlclv4r.fsf@gnu.org> <4F103C20.8070204@gmail.com> <83ipkfk3hg.fsf@gnu.org> <4F117B33.8080906@gmail.com> <834nvyjsqj.fsf@gnu.org> <000001ccd30c$5ce854e0$16b8fea0$%muller@ics-cnrs.unistra.fr> <83sjjhips3.fsf@gnu.org> <20120115133427.GW31383@adacore.com> X-IsSubscribed: yes 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 X-SW-Source: 2012-01/txt/msg00524.txt.bz2 > Date: Sun, 15 Jan 2012 17:34:27 +0400 > From: Joel Brobecker > Cc: Pierre Muller , asmwarrior@gmail.com, > dje@google.com, gdb-patches@sourceware.org > > I am not too sure whether the problems with MSYS also happen on cygwin > or whether you have different issues. But I *think* we solve the problem > by using semi-absolute paths (a path that looks absolute in a Unix > environment, but is only missing the drive letter in the windows > environment). To make it work, we use a directory name that works > in both environments. For instance, if one could have directory c:/gnu/, > and setup cygwin to mount c:/gnu into /gnu. > > And then, one could configure GDB with a prefix such as --prefix=/gnu. > As long as the other directories are configured as a subdirectory of > that prefix, it should work as well as it does for me. If so, that's not what I was looking for. I was looking for a way for GDB to "auto-configure" its directories based on the directory where gdb.exe lives. > > Perhaps Joel could tell where and how the relocation of the standard > > directories happens for him, and then we could try stepping through > > that code with a debugger. > > The relocation happens during startup. Search for "relocate" in > main.c (I think - it should be inside function "captured_main"). > > During your debugging, it would be good to know whether the relocation > is turned off, of whether it is failing. A good way to figure this > out, is to look at the generated gdb/config.h file. Search for "RELOCAT", > and in particular: PYTHON_PATH_RELOCATABLE (I think that's what > matters). Thanks for the pointers, I will have a look. But from what's been said here, I suspect that it "fails" by design.