This is the mail archive of the
mailing list for the GDB project.
Re: Re: gdb with python support still get crash on showing uninitialized local variables
- From: asmwarrior <asmwarrior at gmail dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Joel Brobecker <brobecker at adacore dot com>, tromey at redhat dot com, gdb at sourceware dot org, gdb-patches at sourceware dot org
- Date: Sun, 31 Oct 2010 10:26:43 +0800
- Subject: Re: Re: gdb with python support still get crash on showing uninitialized local variables
- References: <firstname.lastname@example.org>
On 3:59, Eli Zaretskii wrote:
Date: Fri, 29 Oct 2010 15:18:20 -0400
From: Joel Brobecker<email@example.com>
Cc: Tom Tromey<firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com
Yes, because it's a script, the makefile should execute it via $SHELL.
I see that we're making the same error in gdb/doc, for instance, so
it looks like we would be unable to build the documentation if building
using MinGW tools.
If you are using the MinGW port of GNU Make, it will always use sh.exe
(if it can find it on your PATH) automatically to run any shell
scripts invoked by the Makefile. I just tried that with a MinGW build
of Make 3.82, and commands like "./mkinstalldirs foo/bar" just work (I
do have a sh.exe). This works because the function process_begin on
w32/subproc/sub_proc.c has code to detect a Unix shell script and
So there's some other factor at work here. Or maybe the sh.exe which
is installed on the OP's machine has some issues that mine doesn't.
I use the configure make command directly in the MSYS shell. So I think
they by default use the GNU make (not the mingw32-make).
But I run the make -v on the MSYS shell, it gives the version number
3.81. So I will try 3.82 as your mentioned.