From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28548 invoked by alias); 15 Jan 2012 03:33:07 -0000 Received: (qmail 28540 invoked by uid 22791); 15 Jan 2012 03:33:07 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_DB,TW_YG X-Spam-Check-By: sourceware.org Received: from mail-iy0-f169.google.com (HELO mail-iy0-f169.google.com) (209.85.210.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 15 Jan 2012 03:32:52 +0000 Received: by iacb35 with SMTP id b35so151744iac.0 for ; Sat, 14 Jan 2012 19:32:51 -0800 (PST) Received: by 10.50.181.197 with SMTP id dy5mr7188493igc.13.1326598371653; Sat, 14 Jan 2012 19:32:51 -0800 (PST) Received: from [192.168.1.100] ([60.186.227.121]) by mx.google.com with ESMTPS id 5sm48264670ibe.8.2012.01.14.19.32.46 (version=SSLv3 cipher=OTHER); Sat, 14 Jan 2012 19:32:50 -0800 (PST) Message-ID: <4F1249F4.1020203@gmail.com> Date: Sun, 15 Jan 2012 03:54:00 -0000 From: asmwarrior User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Pierre Muller CC: 'Eli Zaretskii' , brobecker@adacore.com, dje@google.com, gdb-patches@sourceware.org Subject: Re: Building GDB 7.3.92 with MinGW References: <83hb03e9sx.fsf@gnu.org> <838vlfe0k9.fsf@gnu.org> <4F0CD948.8080909@gmail.com> <4F0E266C.8080208@gmail.com> <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> <18546.4176851839$1326580387@news.gmane.org> In-Reply-To: <18546.4176851839$1326580387@news.gmane.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/msg00518.txt.bz2 On 2012-1-15 6:32, Pierre Muller wrote: > > After some debugging, > I believe that the main problem is related to the fact > that we use msys environment (which has msys specific mounts) > to compile a mingw32 GDB executable that knows nothing about those msys > mount points! > > config.h > get several entries with directories. > All but WITH_PYTHON_PATH (which is mingw32 compatible) > are msys paths: > DEBUGDIR, GDB_DATADIR and JIT_READER_DIR > but those msys pathes are not interpreted correctly by > a mingw32 executable (i.e. gdb.exe itself). > > I do believe that this is an error in the mingw32 configuration > and that it should be fixed in those configuration files... > > As an example I tried to use --prefix=/e/pas/fpc-2.6.0 > msys /e/ corresponds to e:/ in mingw32, > but > (gdb) py print gdb.PYTHONDIR > e:\e\pas\fpc-2.6.0\share\gdb/python > Of course, this path doesn't even exist on my computer! > If I do substitute /e/ by e:/ inside config.h > and at least get an existing path as output of (gdb) py print gdb.PYTHONDIR > > The bad part is that msys doesn't have a > equivalent of cygpath utitlity, so that I proposed > a solution above, but I have no idea about how > to really implement that solution... > > Pierre Muller > > > > Hi, thank you very much for the testing, and I'm totally agree with you. In my hacky patch, I use one Windows API function: #ifdef _WIN32 int get_app_fullpath(char *location, int length) { int len = GetModuleFileName(0, location, length); return len; } #endif This, I get the path of the gdb.exe, then I adjust the path to get the "share" folder. asmwarrior ollydbg from codeblocks' forum