This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Possible fix for mingw32 directory relocation problems
- From: Doug Evans <dje at google dot com>
- To: Pierre Muller <pierre dot muller at ics-cnrs dot unistra dot fr>
- Cc: gdb-patches at sourceware dot org, Eli Zaretskii <eliz at gnu dot org>, asmwarrior at gmail dot com, Tom Tromey <tromey at redhat dot com>
- Date: Tue, 17 Jan 2012 07:33:53 -0800
- Subject: Re: Possible fix for mingw32 directory relocation problems
- References: <4f143c53.ca3c440a.1d95.ffff9b71SMTPIN_ADDED@mx.google.com> <CADPb22Q+3zmxi4-cr=-ze7eyJEizDqL_Yn2YxtuopKD3ZaDR+A@mail.gmail.com> <4f158a77.833ed80a.629b.7837SMTPIN_ADDED@mx.google.com>
On Tue, Jan 17, 2012 at 6:49 AM, Pierre Muller
<pierre.muller@ics-cnrs.unistra.fr> wrote:
> ?Nevertheless, if you run gdb directly in the compilation directory,
> you will notice the GDB_DATADIR macro set to ?'/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.
> ?Thus, 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=$build_directory/data-directory.
> ?I 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=/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