From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16286 invoked by alias); 17 Jan 2012 15:34:08 -0000 Received: (qmail 16218 invoked by uid 22791); 17 Jan 2012 15:34:07 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Jan 2012 15:33:54 +0000 Received: by vcbfl11 with SMTP id fl11so328992vcb.0 for ; Tue, 17 Jan 2012 07:33:53 -0800 (PST) Received: by 10.220.107.79 with SMTP id a15mr10358664vcp.61.1326814433832; Tue, 17 Jan 2012 07:33:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.79 with SMTP id a15mr10358651vcp.61.1326814433738; Tue, 17 Jan 2012 07:33:53 -0800 (PST) Received: by 10.220.229.1 with HTTP; Tue, 17 Jan 2012 07:33:53 -0800 (PST) In-Reply-To: <4f158a77.833ed80a.629b.7837SMTPIN_ADDED@mx.google.com> References: <4f143c53.ca3c440a.1d95.ffff9b71SMTPIN_ADDED@mx.google.com> <4f158a77.833ed80a.629b.7837SMTPIN_ADDED@mx.google.com> Date: Tue, 17 Jan 2012 16:11:00 -0000 Message-ID: Subject: Re: Possible fix for mingw32 directory relocation problems From: Doug Evans To: Pierre Muller Cc: gdb-patches@sourceware.org, Eli Zaretskii , asmwarrior@gmail.com, Tom Tromey X-System-Of-Record: true Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00597.txt.bz2 On Tue, Jan 17, 2012 at 6:49 AM, Pierre Muller wrote: > =A0Nevertheless, if you run gdb directly in the compilation directory, > you will notice the GDB_DATADIR macro set to =A0'/usr/local/share/gdb' in > config.h > into 'e:\usr\local\share\gdb' > due to a call to lrealpath which calls GetFullPathName if __WIN32 is > defined. A similar thing happens when running gdb from the build directory on all systems, this is not win32 specific. GDB does not (currently) automagically support it. > =A0Thus, I wonder if the correct solution should not be to > convert all the paths in config.h to mingw32 type at configure time. > But, once again, I don't really know how to do this.... When running gdb from the build directory, pass -data-directory=3D$build_directory/data-directory. > =A0I went on to try to use this to test mingw64 Windows-64bit GDB debugger > using Cygwin cross-compiler x86_64-w64-mingw32 target, but > I couldn't get configure to accept the Windows 64-bit 2.7 python... > apparently because not libpython2.7.a is included in the distribution > (the library is, according to web search, non-functional...) > Does anyone know howto force python use for cygwin to mingw64 cross > compilation of GDB? I'm not sure the issue I'm referring to below is the issue you're running into, but Python doesn't handle cross compilation very well, and one workaround is the following hack. When configuring gdb pass --with-python=3D/path/to/config-python-hack, where /path/to/config-python-hack is a script like the following: [edit the paths in this example to match your environment] #! /bin/sh if [ $# -ne 2 ] then echo "Bad # args. Blech!" >&2 exit 1 fi # The first argument is the path to python-config.py, ignore it. case "$2" in --includes) echo "-I/usr/include/python2.6 -I/usr/include/python2.6" ;; --ldflags) echo "-L/usr/lib/python2.6/config -lpthread -ldl -lutil -lm -lpython2.6" ;; --exec-prefix) echo "/usr" ;; *) echo "Bad arg $2. Blech!" >&2 ; exit 1 ;; esac exit 0