Building GDB 7.3.92 with MinGW

Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

I've successfully built the latest pretest of GDB 7.3.92 with MinGW on
MS-Windows.  But I did encounter a few minor issues; this is my report
about them.

1. Compilation warning:

     gcc -O2 -gdwarf-2 -g3 -D__USE_MINGW_ACCESS   -I. -I. -I./common -I./config -DLOCALEDIR="\"/d/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./../intl -I./gnulib -Ignulib    -I/d/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wno-format  -c -o utils.o -MT utils.o -MMD -MP -MF .deps/utils.Tpo utils.c
     In file included from gdb_curses.h:30,
		      from utils.c:68:
     d:/usr/include/curses.h:153:1: warning: "MOUSE_MOVED" redefined
     In file included from d:/usr/include/windows.h:49,
		      from d:/usr/include/winsock2.h:22,
		      from serial.h:24,
		      from utils.c:48:
     d:/usr/include/wincon.h:58:1: warning: this is the location of the previous definition

  Any objections to the following patch?  (If approved, I will add a
  comment explaining the problem on Windows which requires this.)

     --- gdb/gdb_curses.h~0	2012-01-06 06:43:14.000000000 +0200
     +++ gdb/gdb_curses.h	2012-01-10 13:21:10.626119900 +0200
     @@ -27,6 +27,9 @@
      #elif defined (HAVE_CURSESX_H)
      #include <cursesX.h>
      #elif defined (HAVE_CURSES_H)
     +#if defined(__MINGW32__) && defined(MOUSE_MOVED)
     +#undef MOUSE_MOVED
     +#endif
      #include <curses.h>
      #endif

2. "make install-strip" fails in readline/, in sim/, and in gdb/:

     make[2]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/readline'
     make[2]: *** No rule to make target `install-strip'.  Stop.
     make[2]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92/readline'
     make[1]: *** [install-strip-readline] Error 2
     make[2]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/sim'
     make[2]: *** No rule to make target `install-strip'.
     make[2]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92/sim'
     make[1]: *** [install-strip-sim] Error 2
     make[2]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/gdb'
     make[2]: *** No rule to make target `install-strip'.
     make[2]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92/gdb'
     make[1]: *** [install-strip-gdb] Error 2
     make[1]: Target `install-strip-host' not remade because of errors.
     make[1]: Nothing to be done for `install-strip-target'.
     make[1]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92'
     make: *** [install-strip] Error 2

   The reason is that these directories simply don't have the
   "install-strip" target in their Makefile.in files.  I think that
   target should be added, because that's AFAIK how GDB is supposed to
   be installed on end-user systems.

3. Manuals are (unexpectedly) regenerated as part of "make":

     make[4]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/gdb'
     make[5]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/gdb/doc'
     (test "cp -p" = "ln -s" && \
	       ln -s ./all-cfg.texi gdb-cfg.texi) || \
	     ln ./all-cfg.texi gdb-cfg.texi || \
	     cp ./all-cfg.texi gdb-cfg.texi
     echo "@set GDBVN `sed q ./../version.in`" > ./GDBvn.new
     if [ -n "(GDB) " ]; then \
	       echo "@set VERSION_PACKAGE (GDB) " >> ./GDBvn.new; \
	     fi
     echo "@set BUGURL @uref{http://www.gnu.org/software/gdb/bugs/}" >> ./GDBvn.new
     if [ "@uref{http://www.gnu.org/software/gdb/bugs/}" = "@uref{http://www.gnu.org/software/gdb/bugs/}" ]; then \
	       echo "@set BUGURL_DEFAULT" >> ./GDBvn.new; \
	     fi
     if test -z "-I ./../../readline/doc"; then \
	       echo "@set SYSTEM_READLINE" >> ./GDBvn.new; \
	     fi
     mv GDBvn.new GDBvn.texi
     makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 -DHAVE_MAKEINFO_CLICK -I ./../../readline/doc -I ./../mi -I . \
		     -o gdb.info ./gdb.texinfo
     makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 -DHAVE_MAKEINFO_CLICK -I . -o gdbint.info ./gdbint.texinfo
     makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 -DHAVE_MAKEINFO_CLICK -I . -o annotate.info ./annotate.texinfo

   The reason is that gdb-cfg.texi and GDBvn.texi are not in the
   tarball, but they are build dependencies of the manuals:

     GDB_DOC_BUILD_INCLUDES = \
	     gdb-cfg.texi \
	     GDBvn.texi
     GDB_DOC_FILES = \
	     $(srcdir)/gdb.texinfo \
	     $(GDB_DOC_SOURCE_INCLUDES) \
	     $(GDB_DOC_BUILD_INCLUDES)
     ...
     # GDB MANUAL: info file
     gdb.info: ${GDB_DOC_FILES}
	     $(MAKEINFO_CMD) $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \
		     -o gdb.info $(srcdir)/gdb.texinfo

   I think these two files should be added to the distribution, since
   end users should not be required to have Texinfo installed to build
   GDB.

Finally, a question: Why are we installing libraries (libbfd,
libopcodes, libiberty) and the standards.info manual?  The libraries
are not part of GDB, we import them from elsewhere.  "make install"
will happily overwrite existing installation of these libraries that
could potentially be newer, coming from their respective upstream
distributions.  How about removing these from "make install"?

As for standards.info, if we decide to keep distributing it (which I
don't think we should), we should at least make a point of having the
latest version in our tarballs; the one in 7.3.92 isn't.

TIA

Re: Building GDB 7.3.92 with MinGW

[Doug Evans]

On Tue, Jan 10, 2012 at 9:39 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> I've successfully built the latest pretest of GDB 7.3.92 with MinGW on
> MS-Windows.  But I did encounter a few minor issues; this is my report
> about them.
>
> 1. Compilation warning:
>
>     gcc -O2 -gdwarf-2 -g3 -D__USE_MINGW_ACCESS   -I. -I. -I./common -I./config -DLOCALEDIR="\"/d/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./../intl -I./gnulib -Ignulib    -I/d/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wno-format  -c -o utils.o -MT utils.o -MMD -MP -MF .deps/utils.Tpo utils.c
>     In file included from gdb_curses.h:30,
>                      from utils.c:68:
>     d:/usr/include/curses.h:153:1: warning: "MOUSE_MOVED" redefined
>     In file included from d:/usr/include/windows.h:49,
>                      from d:/usr/include/winsock2.h:22,
>                      from serial.h:24,
>                      from utils.c:48:
>     d:/usr/include/wincon.h:58:1: warning: this is the location of the previous definition
>
>  Any objections to the following patch?  (If approved, I will add a
>  comment explaining the problem on Windows which requires this.)
>
>     --- gdb/gdb_curses.h~0     2012-01-06 06:43:14.000000000 +0200
>     +++ gdb/gdb_curses.h       2012-01-10 13:21:10.626119900 +0200
>     @@ -27,6 +27,9 @@
>      #elif defined (HAVE_CURSESX_H)
>      #include <cursesX.h>
>      #elif defined (HAVE_CURSES_H)
>     +#if defined(__MINGW32__) && defined(MOUSE_MOVED)
>     +#undef MOUSE_MOVED
>     +#endif
>      #include <curses.h>
>      #endif

This is ok with me but remove the "&& defined(MOUSE_MOVED)".
And one space after defined in "defined(__MINGW32__)".

>
> 2. "make install-strip" fails in readline/, in sim/, and in gdb/:
>
>     make[2]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/readline'
>     make[2]: *** No rule to make target `install-strip'.  Stop.
>     make[2]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92/readline'
>     make[1]: *** [install-strip-readline] Error 2
>     make[2]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/sim'
>     make[2]: *** No rule to make target `install-strip'.
>     make[2]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92/sim'
>     make[1]: *** [install-strip-sim] Error 2
>     make[2]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/gdb'
>     make[2]: *** No rule to make target `install-strip'.
>     make[2]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92/gdb'
>     make[1]: *** [install-strip-gdb] Error 2
>     make[1]: Target `install-strip-host' not remade because of errors.
>     make[1]: Nothing to be done for `install-strip-target'.
>     make[1]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92'
>     make: *** [install-strip] Error 2
>
>   The reason is that these directories simply don't have the
>   "install-strip" target in their Makefile.in files.  I think that
>   target should be added, because that's AFAIK how GDB is supposed to
>   be installed on end-user systems.

Sounds reasonable, but something to leave for 7.5?

> 3. Manuals are (unexpectedly) regenerated as part of "make":
>
>     make[4]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/gdb'
>     make[5]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/gdb/doc'
>     (test "cp -p" = "ln -s" && \
>               ln -s ./all-cfg.texi gdb-cfg.texi) || \
>             ln ./all-cfg.texi gdb-cfg.texi || \
>             cp ./all-cfg.texi gdb-cfg.texi
>     echo "@set GDBVN `sed q ./../version.in`" > ./GDBvn.new
>     if [ -n "(GDB) " ]; then \
>               echo "@set VERSION_PACKAGE (GDB) " >> ./GDBvn.new; \
>             fi
>     echo "@set BUGURL @uref{http://www.gnu.org/software/gdb/bugs/}" >> ./GDBvn.new
>     if [ "@uref{http://www.gnu.org/software/gdb/bugs/}" = "@uref{http://www.gnu.org/software/gdb/bugs/}" ]; then \
>               echo "@set BUGURL_DEFAULT" >> ./GDBvn.new; \
>             fi
>     if test -z "-I ./../../readline/doc"; then \
>               echo "@set SYSTEM_READLINE" >> ./GDBvn.new; \
>             fi
>     mv GDBvn.new GDBvn.texi
>     makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 -DHAVE_MAKEINFO_CLICK -I ./../../readline/doc -I ./../mi -I . \
>                     -o gdb.info ./gdb.texinfo
>     makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 -DHAVE_MAKEINFO_CLICK -I . -o gdbint.info ./gdbint.texinfo
>     makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 -DHAVE_MAKEINFO_CLICK -I . -o annotate.info ./annotate.texinfo
>
>   The reason is that gdb-cfg.texi and GDBvn.texi are not in the
>   tarball, but they are build dependencies of the manuals:
>
>     GDB_DOC_BUILD_INCLUDES = \
>             gdb-cfg.texi \
>             GDBvn.texi
>     GDB_DOC_FILES = \
>             $(srcdir)/gdb.texinfo \
>             $(GDB_DOC_SOURCE_INCLUDES) \
>             $(GDB_DOC_BUILD_INCLUDES)
>     ...
>     # GDB MANUAL: info file
>     gdb.info: ${GDB_DOC_FILES}
>             $(MAKEINFO_CMD) $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \
>                     -o gdb.info $(srcdir)/gdb.texinfo
>
>   I think these two files should be added to the distribution, since
>   end users should not be required to have Texinfo installed to build
>   GDB.

Sounds reasonable to me, but it seems odd.
Why hasn't this come up before?
[Users are indeed not required to have texinfo.]

> Finally, a question: Why are we installing libraries (libbfd,
> libopcodes, libiberty) and the standards.info manual?  The libraries
> are not part of GDB, we import them from elsewhere.  "make install"
> will happily overwrite existing installation of these libraries that
> could potentially be newer, coming from their respective upstream
> distributions.  How about removing these from "make install"?

I don't have an opinion on this.
A counter argument could be that someone may already be expecting them
to be installed.

> As for standards.info, if we decide to keep distributing it (which I
> don't think we should), we should at least make a point of having the
> latest version in our tarballs; the one in 7.3.92 isn't.

Minor preference for keeping it, I've gotten used to it being installed.

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Tue, 10 Jan 2012 10:46:24 -0800
> From: Doug Evans <dje@google.com>
> Cc: gdb-patches@sourceware.org
> 
> >   The reason is that gdb-cfg.texi and GDBvn.texi are not in the
> >   tarball, but they are build dependencies of the manuals:
> >
> >     GDB_DOC_BUILD_INCLUDES = \
> >             gdb-cfg.texi \
> >             GDBvn.texi
> >     GDB_DOC_FILES = \
> >             $(srcdir)/gdb.texinfo \
> >             $(GDB_DOC_SOURCE_INCLUDES) \
> >             $(GDB_DOC_BUILD_INCLUDES)
> >     ...
> >     # GDB MANUAL: info file
> >     gdb.info: ${GDB_DOC_FILES}
> >             $(MAKEINFO_CMD) $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \
> >                     -o gdb.info $(srcdir)/gdb.texinfo
> >
> >   I think these two files should be added to the distribution, since
> >   end users should not be required to have Texinfo installed to build
> >   GDB.
> 
> Sounds reasonable to me, but it seems odd.
> Why hasn't this come up before?

I have no idea.  Maybe it's some remnant from the times, not so long
ago, when manuals weren't produced unless you said "make info".

> > As for standards.info, if we decide to keep distributing it (which I
> > don't think we should), we should at least make a point of having the
> > latest version in our tarballs; the one in 7.3.92 isn't.
> 
> Minor preference for keeping it, I've gotten used to it being installed.

You can always get it from its origin, which is here:

   http://www.gnu.org/prep/standards/standards.texi.tar.gz

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Tue, 10 Jan 2012 10:46:24 -0800
> From: Doug Evans <dje@google.com>
> Cc: gdb-patches@sourceware.org
> 
> On Tue, Jan 10, 2012 at 9:39 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > I've successfully built the latest pretest of GDB 7.3.92 with MinGW on
> > MS-Windows.  But I did encounter a few minor issues; this is my report
> > about them.
> >
> > 1. Compilation warning:
> >
> >     gcc -O2 -gdwarf-2 -g3 -D__USE_MINGW_ACCESS   -I. -I. -I./common -I./config -DLOCALEDIR="\"/d/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./../intl -I./gnulib -Ignulib    -I/d/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wno-format  -c -o utils.o -MT utils.o -MMD -MP -MF .deps/utils.Tpo utils.c
> >     In file included from gdb_curses.h:30,
> >                      from utils.c:68:
> >     d:/usr/include/curses.h:153:1: warning: "MOUSE_MOVED" redefined
> >     In file included from d:/usr/include/windows.h:49,
> >                      from d:/usr/include/winsock2.h:22,
> >                      from serial.h:24,
> >                      from utils.c:48:
> >     d:/usr/include/wincon.h:58:1: warning: this is the location of the previous definition
> >
> >  Any objections to the following patch?  (If approved, I will add a
> >  comment explaining the problem on Windows which requires this.)
> >
> >     --- gdb/gdb_curses.h~0     2012-01-06 06:43:14.000000000 +0200
> >     +++ gdb/gdb_curses.h       2012-01-10 13:21:10.626119900 +0200
> >     @@ -27,6 +27,9 @@
> >      #elif defined (HAVE_CURSESX_H)
> >      #include <cursesX.h>
> >      #elif defined (HAVE_CURSES_H)
> >     +#if defined(__MINGW32__) && defined(MOUSE_MOVED)
> >     +#undef MOUSE_MOVED
> >     +#endif
> >      #include <curses.h>
> >      #endif
> 
> This is ok with me but remove the "&& defined(MOUSE_MOVED)".
> And one space after defined in "defined(__MINGW32__)".

Thanks.  Here's what I committed, trunk and branch:

 Avoid compiler warnings in gdb_curses.h on MinGW.

 See http://sourceware.org/ml/gdb-patches/2012-01/msg00298.html
 for more details about the problem.

  gdb/gdb_curses.h (MOUSE_MOVED) [__MINGW32__]: Undefine before
  including curses.h.

Index: gdb/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.13735
retrieving revision 1.13736
diff -u -r1.13735 -r1.13736
--- gdb/ChangeLog	12 Jan 2012 23:38:46 -0000	1.13735
+++ gdb/ChangeLog	13 Jan 2012 10:44:35 -0000	1.13736
@@ -1,3 +1,8 @@
+2012-01-13  Eli Zaretskii  <eliz@gnu.org>
+
+	* gdb_curses.h (MOUSE_MOVED) [__MINGW32__]: Undefine before
+	including curses.h.
+
 2012-01-12  Jan Kratochvil  <jan.kratochvil@redhat.com>
 
 	* configure: Regenerate.


Index: gdb/gdb_curses.h
===================================================================
RCS file: /cvs/src/src/gdb/gdb_curses.h,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- gdb/gdb_curses.h	4 Jan 2012 08:17:02 -0000	1.14
+++ gdb/gdb_curses.h	13 Jan 2012 10:44:35 -0000	1.15
@@ -27,6 +27,14 @@
 #elif defined (HAVE_CURSESX_H)
 #include <cursesX.h>
 #elif defined (HAVE_CURSES_H)
+#ifdef __MINGW32__
+/* Windows API headers, included e.g. by serial.h, define MOUSE_MOVED,
+   and so does PDCurses's curses.h, but for an entirely different
+   purpose.  Since we don't use the Windows semantics of MOUSE_MOVED
+   anywhere, avoid compiler warnings by undefining MOUSE_MOVED before
+   including curses.h.  */
+#undef MOUSE_MOVED
+#endif
 #include <curses.h>
 #endif
 

Re: Building GDB 7.3.92 with MinGW

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli>   Any objections to the following patch?  (If approved, I will add a
Eli>   comment explaining the problem on Windows which requires this.)
Eli>      --- gdb/gdb_curses.h~0	2012-01-06 06:43:14.000000000 +0200
Eli>      +++ gdb/gdb_curses.h	2012-01-10 13:21:10.626119900 +0200
Eli>      @@ -27,6 +27,9 @@
Eli>       #elif defined (HAVE_CURSESX_H)
Eli>       #include <cursesX.h>
Eli>       #elif defined (HAVE_CURSES_H)
Eli>      +#if defined(__MINGW32__) && defined(MOUSE_MOVED)
Eli>      +#undef MOUSE_MOVED
Eli>      +#endif
Eli>       #include <curses.h>
Eli>       #endif

I don't really mind this patch.  But, why is this something for gdb to
solve rather than mingw?

Eli> 2. "make install-strip" fails in readline/, in sim/, and in gdb/:

Eli>    The reason is that these directories simply don't have the
Eli>    "install-strip" target in their Makefile.in files.  I think that
Eli>    target should be added, because that's AFAIK how GDB is supposed to
Eli>    be installed on end-user systems.

This is in the GNU standards, but in practice few people use it.

Of course, patches are welcome.  This isn't the only places where gdb's
Makefiles diverge from the standards.

Eli> 3. Manuals are (unexpectedly) regenerated as part of "make":

Eli>    I think these two files should be added to the distribution, since
Eli>    end users should not be required to have Texinfo installed to build
Eli>    GDB.

No opinion on this one.

Eli> Finally, a question: Why are we installing libraries (libbfd,
Eli> libopcodes, libiberty) and the standards.info manual?  The libraries
Eli> are not part of GDB, we import them from elsewhere.  "make install"
Eli> will happily overwrite existing installation of these libraries that
Eli> could potentially be newer, coming from their respective upstream
Eli> distributions.  How about removing these from "make install"?

For libiberty, gcc is the authoritative source.  So, ask there.

For the others, ask on the binutils list.

I tend to agree they should not be installed.

Eli> As for standards.info, if we decide to keep distributing it (which I
Eli> don't think we should), we should at least make a point of having the
Eli> latest version in our tarballs; the one in 7.3.92 isn't.

IMO we should remove this.  Actually, most of the things in src/etc seem
outdated or useless or somebody else's code.

I'm not sure who owns this directory, you should ask on binutils before
taking any action.

Tom

Re: Building GDB 7.3.92 with MinGW

[Joseph S. Myers]

On Tue, 10 Jan 2012, Tom Tromey wrote:

> Eli> Finally, a question: Why are we installing libraries (libbfd,
> Eli> libopcodes, libiberty) and the standards.info manual?  The libraries
> Eli> are not part of GDB, we import them from elsewhere.  "make install"
> Eli> will happily overwrite existing installation of these libraries that
> Eli> could potentially be newer, coming from their respective upstream
> Eli> distributions.  How about removing these from "make install"?
> 
> For libiberty, gcc is the authoritative source.  So, ask there.

My view is that libiberty should not be installed (unless 
--enable-install-libiberty or --enable-install-libbfd).  (These options 
already exist; it's just some defaults that are installing too much; maybe 
in some cases the options only control the headers not the libraries.)

http://gcc.gnu.org/wiki/ImprovementProjects#Toplevel_configuration_and_build_system

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: gdb-patches@sourceware.org
> Date: Tue, 10 Jan 2012 12:12:14 -0700
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli>   Any objections to the following patch?  (If approved, I will add a
> Eli>   comment explaining the problem on Windows which requires this.)
> Eli>      --- gdb/gdb_curses.h~0	2012-01-06 06:43:14.000000000 +0200
> Eli>      +++ gdb/gdb_curses.h	2012-01-10 13:21:10.626119900 +0200
> Eli>      @@ -27,6 +27,9 @@
> Eli>       #elif defined (HAVE_CURSESX_H)
> Eli>       #include <cursesX.h>
> Eli>       #elif defined (HAVE_CURSES_H)
> Eli>      +#if defined(__MINGW32__) && defined(MOUSE_MOVED)
> Eli>      +#undef MOUSE_MOVED
> Eli>      +#endif
> Eli>       #include <curses.h>
> Eli>       #endif
> 
> I don't really mind this patch.  But, why is this something for gdb to
> solve rather than mingw?

Unlikely: it's the problem between PDCurses and the MS-Windows API
header files.

> Eli> 2. "make install-strip" fails in readline/, in sim/, and in gdb/:
> 
> Eli>    The reason is that these directories simply don't have the
> Eli>    "install-strip" target in their Makefile.in files.  I think that
> Eli>    target should be added, because that's AFAIK how GDB is supposed to
> Eli>    be installed on end-user systems.
> 
> This is in the GNU standards, but in practice few people use it.
> 
> Of course, patches are welcome.  This isn't the only places where gdb's
> Makefiles diverge from the standards.

I'll try.

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: gdb-patches@sourceware.org
> Date: Tue, 10 Jan 2012 12:12:14 -0700
> 
> Eli> Finally, a question: Why are we installing libraries (libbfd,
> Eli> libopcodes, libiberty) and the standards.info manual?  The libraries
> Eli> are not part of GDB, we import them from elsewhere.  "make install"
> Eli> will happily overwrite existing installation of these libraries that
> Eli> could potentially be newer, coming from their respective upstream
> Eli> distributions.  How about removing these from "make install"?
> 
> For libiberty, gcc is the authoritative source.  So, ask there.

Let's start with DJ.  DJ, any comments on the libiberty part?

Re: Building GDB 7.3.92 with MinGW

[Alfred M. Szmidt]

   2. "make install-strip" fails in readline/, in sim/, and in gdb/:

	make[2]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/readline'
	make[2]: *** No rule to make target `install-strip'.  Stop.
	make[2]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92/readline'
	make[1]: *** [install-strip-readline] Error 2
	make[2]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/sim'
	make[2]: *** No rule to make target `install-strip'.
	make[2]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92/sim'
	make[1]: *** [install-strip-sim] Error 2
	make[2]: Entering directory `/d/usr/eli/utils/gdb-7.3.92/gdb'
	make[2]: *** No rule to make target `install-strip'.
	make[2]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92/gdb'
	make[1]: *** [install-strip-gdb] Error 2
	make[1]: Target `install-strip-host' not remade because of errors.
	make[1]: Nothing to be done for `install-strip-target'.
	make[1]: Leaving directory `/d/usr/eli/utils/gdb-7.3.92'
	make: *** [install-strip] Error 2

      The reason is that these directories simply don't have the
      "install-strip" target in their Makefile.in files.  I think that
      target should be added, because that's AFAIK how GDB is supposed
      to be installed on end-user systems.

`make install' is generally the way one should install GNU projects on
a end-user system, since that makes it possible to debug things (hence
why CFLAGS contains -g by default); install-strip is really for people
with little disk space.

   Finally, a question: Why are we installing libraries (libbfd,
   libopcodes, libiberty) and the standards.info manual?  The
   libraries are not part of GDB, we import them from elsewhere.
   "make install" will happily overwrite existing installation of
   these libraries that could potentially be newer, coming from their
   respective upstream distributions.  How about removing these from
   "make install"?

I personally never understood why they get installed by binutils, or
gdb.

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Tue, 10 Jan 2012 14:25:11 -0500
> From: ams@gnu.org (Alfred M. Szmidt)
> CC: gdb-patches@sourceware.org
> 
> `make install' is generally the way one should install GNU projects on
> a end-user system, since that makes it possible to debug things (hence
> why CFLAGS contains -g by default); install-strip is really for people
> with little disk space.

Well, an unstripped GDB weighs in at some 47MB, which is just too
much.

And you can't usefully debug it outside of the source tree anyway.

I normally keep the unstripped binary with the sources, but install
stripped ones.

Re: Building GDB 7.3.92 with MinGW

[Doug Evans]

On Tue, Jan 10, 2012 at 12:59 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 10 Jan 2012 14:25:11 -0500
>> From: ams@gnu.org (Alfred M. Szmidt)
>> CC: gdb-patches@sourceware.org
>>
>> `make install' is generally the way one should install GNU projects on
>> a end-user system, since that makes it possible to debug things (hence
>> why CFLAGS contains -g by default); install-strip is really for people
>> with little disk space.
>
> Well, an unstripped GDB weighs in at some 47MB, which is just too
> much.
>
> And you can't usefully debug it outside of the source tree anyway.

Well, having the sources is useful of course :-), but for reference
sake there is value in debugging gdb outside of the *build* tree.
i.e. debugging the installed copy.
gdb is now more dependent on ancillary files (python, etc.) and it's
useful to run gdb the way users run it.
For one, remembering to pass -data-directory is a pain. :-)

Re: Building GDB 7.3.92 with MinGW

[asmwarrior]

On 2012-1-11 5:23, Doug Evans wrote:
> For one, remembering to pass -data-directory is a pain.

This parameter does not work correctly under MinGW in the case that I would like gdb to automatically run the python script when it startup.

Normally, my gdb is put in MinGW/bin, and the gdb's own python script is under:
MinGW\share\gdb\python\gdb\*.py

I need to hard-code the code in gdb/main.c to set the data-directory value. (Because gdb is build from MSYS+MinGW, but it run normally on Windows shell without MSYS)

Here are some hard-code modify to the main.c file, if you do not change this, there is no way to load gdb's own python scripts.

diff --git a/gdb/main.c b/gdb/main.c
index 8b45c25..46b11a8 100644
--- a/gdb/main.c
+++ b/gdb/main.c
@@ -42,6 +42,10 @@
  #include "python/python.h"
  #include "objfiles.h"
  
+#ifdef _WIN32
+extern int get_app_fullpath(char *location, int length);
+#endif
+
  /* The selected interpreter.  This will be used as a set command
     variable, so it should always be malloc'ed - since
     do_setshow_command will free it.  */
@@ -355,8 +359,27 @@ captured_main (void *data)
    debug_file_directory = relocate_gdb_directory (DEBUGDIR,
  						 DEBUGDIR_RELOCATABLE);
  
+
+#ifdef _WIN32
+  {
+    char location[500];
+    int len= get_app_fullpath(location, sizeof (location));
+    if (len == 0 || len > 500 - 1)
+      gdb_datadir = relocate_gdb_directory (GDB_DATADIR,GDB_DATADIR_RELOCATABLE);
+    else
+    {
+        char *p_slash =strrchr(location,'\\');
+        *p_slash = '\000';
+        p_slash =strrchr(location,'\\'); /* remove the bin folder*/
+        *p_slash = '\000';
+        strcat(location,"\\share\\gdb");
+        gdb_datadir = xstrdup (location);
+    }
+  }
+#else
    gdb_datadir = relocate_gdb_directory (GDB_DATADIR,
-					GDB_DATADIR_RELOCATABLE);
+					GDB_DATADIR_RELOCATABLE);
+#endif
  
  #ifdef WITH_PYTHON_PATH
    {

If I remember correctly, I have post it some months ago.

asmwarrior
ollydbg from codeblocks' forum

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Wed, 11 Jan 2012 08:35:20 +0800
> From: asmwarrior <asmwarrior@gmail.com>
> 
> On 2012-1-11 5:23, Doug Evans wrote:
> > For one, remembering to pass -data-directory is a pain.
> 
> This parameter does not work correctly under MinGW in the case that I would like gdb to automatically run the python script when it startup.
> 
> Normally, my gdb is put in MinGW/bin, and the gdb's own python script is under:
> MinGW\share\gdb\python\gdb\*.py
> 
> I need to hard-code the code in gdb/main.c to set the data-directory value. (Because gdb is build from MSYS+MinGW, but it run normally on Windows shell without MSYS)

Can you explain why the original code doesn't work as intended?  And
what is MSYS have to do with that?

Thanks.

Re: Building GDB 7.3.92 with MinGW

[asmwarrior]

On 2012-1-11 12:05, Eli Zaretskii wrote:
>> Date: Wed, 11 Jan 2012 08:35:20 +0800
>> From: asmwarrior<asmwarrior@gmail.com>
>>
>> On 2012-1-11 5:23, Doug Evans wrote:
>>> For one, remembering to pass -data-directory is a pain.
>> This parameter does not work correctly under MinGW in the case that I would like gdb to automatically run the python script when it startup.
>>
>> Normally, my gdb is put in MinGW/bin, and the gdb's own python script is under:
>> MinGW\share\gdb\python\gdb\*.py
>>
>> I need to hard-code the code in gdb/main.c to set the data-directory value. (Because gdb is build from MSYS+MinGW, but it run normally on Windows shell without MSYS)
> Can you explain why the original code doesn't work as intended?  And
> what is MSYS have to do with that?
>
> Thanks.
Hi, I was originally open a discussion on the Codeblocks' forum

http://forums.codeblocks.org/index.php/topic,15104.0.html

The major problem is:

gdb/main.c (setting the gdb's python folder) execute before we use data-directory to set the python path, so whether you set -data-directory, you always failed to find its own python script.

You can check my patch and see what I adjust the path, so gdb can find and run its own python script correctly.

This issue is that MSYS+autoconf system use different path scheme with normal mingw. But when you run gdb under normal mingw, you still have some internal variables which is MSYS style.

asmwarrior
ollydbg from codeblocks' forum

Re: Building GDB 7.3.92 with MinGW

[Doug Evans]

On Tue, Jan 10, 2012 at 4:35 PM, asmwarrior <asmwarrior@gmail.com> wrote:
> On 2012-1-11 5:23, Doug Evans wrote:
>>
>> For one, remembering to pass -data-directory is a pain.
>
>
> This parameter does not work correctly under MinGW in the case that I would
> like gdb to automatically run the python script when it startup.

When you say "run the python script", *which* python script are you
referring to?

> Normally, my gdb is put in MinGW/bin, and the gdb's own python script is
> under:
> MinGW\share\gdb\python\gdb\*.py
>
> I need to hard-code the code in gdb/main.c to set the data-directory value.
> (Because gdb is build from MSYS+MinGW, but it run normally on Windows shell
> without MSYS)
>
> Here are some hard-code modify to the main.c file, if you do not change
> this, there is no way to load gdb's own python scripts.
>
> diff --git a/gdb/main.c b/gdb/main.c
> index 8b45c25..46b11a8 100644
> --- a/gdb/main.c
> +++ b/gdb/main.c
> @@ -42,6 +42,10 @@
>  #include "python/python.h"
>  #include "objfiles.h"
>  +#ifdef _WIN32
> +extern int get_app_fullpath(char *location, int length);
> +#endif
> +
>  /* The selected interpreter.  This will be used as a set command
>    variable, so it should always be malloc'ed - since
>    do_setshow_command will free it.  */
> @@ -355,8 +359,27 @@ captured_main (void *data)
>   debug_file_directory = relocate_gdb_directory (DEBUGDIR,
>                                                 DEBUGDIR_RELOCATABLE);
>  +
> +#ifdef _WIN32
> +  {
> +    char location[500];
> +    int len= get_app_fullpath(location, sizeof (location));
> +    if (len == 0 || len > 500 - 1)
> +      gdb_datadir = relocate_gdb_directory
> (GDB_DATADIR,GDB_DATADIR_RELOCATABLE);
> +    else
> +    {
> +        char *p_slash =strrchr(location,'\\');
> +        *p_slash = '\000';
> +        p_slash =strrchr(location,'\\'); /* remove the bin folder*/
> +        *p_slash = '\000';
> +        strcat(location,"\\share\\gdb");
> +        gdb_datadir = xstrdup (location);
> +    }
> +  }
> +#else
>   gdb_datadir = relocate_gdb_directory (GDB_DATADIR,
> -                                       GDB_DATADIR_RELOCATABLE);
> +                                       GDB_DATADIR_RELOCATABLE);
> +#endif
>  #ifdef WITH_PYTHON_PATH
>   {
>
> If I remember correctly, I have post it some months ago.

*If* there is a bug here, and it's not pilot error, it feels like
perhaps the bug is in relocate_gdb_directory.
[Why don't all calls to relocate_gdb_directory require similar treatment?
Thus this feels like the wrong way to go.]

Maybe if you provide a sample session (and complete session please, no
editing to trim it down), that will help.

Re: Building GDB 7.3.92 with MinGW

[asmwarrior]

On 2012-1-12 1:48, Doug Evans wrote:
> On Tue, Jan 10, 2012 at 4:35 PM, asmwarrior<asmwarrior@gmail.com>  wrote:
>> On 2012-1-11 5:23, Doug Evans wrote:
>>> For one, remembering to pass -data-directory is a pain.
>>
>> This parameter does not work correctly under MinGW in the case that I would
>> like gdb to automatically run the python script when it startup.
> When you say "run the python script", *which* python script are you
> referring to?
The script code is embedded in c source code in "python.c", in function: voidfinish_python_initialization (void)
>
>> Normally, my gdb is put in MinGW/bin, and the gdb's own python script is
>> under:
>> MinGW\share\gdb\python\gdb\*.py
>>
>> I need to hard-code the code in gdb/main.c to set the data-directory value.
>> (Because gdb is build from MSYS+MinGW, but it run normally on Windows shell
>> without MSYS)
>>
>> Here are some hard-code modify to the main.c file, if you do not change
>> this, there is no way to load gdb's own python scripts.
>>
>> diff --git a/gdb/main.c b/gdb/main.c
>> index 8b45c25..46b11a8 100644
>> --- a/gdb/main.c
>> +++ b/gdb/main.c
>> @@ -42,6 +42,10 @@
>>   #include "python/python.h"
>>   #include "objfiles.h"
>>   +#ifdef _WIN32
>> +extern int get_app_fullpath(char *location, int length);
>> +#endif
>> +
>>   /* The selected interpreter.  This will be used as a set command
>>     variable, so it should always be malloc'ed - since
>>     do_setshow_command will free it.  */
>> @@ -355,8 +359,27 @@ captured_main (void *data)
>>    debug_file_directory = relocate_gdb_directory (DEBUGDIR,
>>                                                  DEBUGDIR_RELOCATABLE);
>>   +
>> +#ifdef _WIN32
>> +  {
>> +    char location[500];
>> +    int len= get_app_fullpath(location, sizeof (location));
>> +    if (len == 0 || len>  500 - 1)
>> +      gdb_datadir = relocate_gdb_directory
>> (GDB_DATADIR,GDB_DATADIR_RELOCATABLE);
>> +    else
>> +    {
>> +        char *p_slash =strrchr(location,'\\');
>> +        *p_slash = '\000';
>> +        p_slash =strrchr(location,'\\'); /* remove the bin folder*/
>> +        *p_slash = '\000';
>> +        strcat(location,"\\share\\gdb");
>> +        gdb_datadir = xstrdup (location);
>> +    }
>> +  }
>> +#else
>>    gdb_datadir = relocate_gdb_directory (GDB_DATADIR,
>> -                                       GDB_DATADIR_RELOCATABLE);
>> +                                       GDB_DATADIR_RELOCATABLE);
>> +#endif
>>   #ifdef WITH_PYTHON_PATH
>>    {
>>
>> If I remember correctly, I have post it some months ago.
> *If* there is a bug here, and it's not pilot error, it feels like
> perhaps the bug is in relocate_gdb_directory.
> [Why don't all calls to relocate_gdb_directory require similar treatment?
> Thus this feels like the wrong way to go.]
>
> Maybe if you provide a sample session (and complete session please, no
> editing to trim it down), that will help.
I have just look at my notes half years ago(no time to write a complete session right now), the issue is:
In the file:

build\gdb\config.status

The value is hard-coded:

D["DEBUGDIR"]=" \"/mingw/lib/debug\""
D["DEBUGDIR_RELOCATABLE"]=" 1"
D["GDB_DATADIR"]=" \"/mingw/share/gdb\""

There are some code snippet:

gdb_program_name = xstrdup (argv[0]);

  if (! getcwd (gdb_dirbuf, sizeof (gdb_dirbuf)))
     /* Don't use *_filtered or warning() (which relies on
       current_target) until after initialize_all_files().  */
     fprintf_unfiltered (gdb_stderr,
            _("%s: warning: error finding "
              "working directory: %s\n"),
                        argv[0], safe_strerror (errno));

  current_directory = gdb_dirbuf;

  /* Set the sysroot path.  */
  gdb_sysroot = relocate_gdb_directory (TARGET_SYSTEM_ROOT,
                    TARGET_SYSTEM_ROOT_RELOCATABLE);

  debug_file_directory = relocate_gdb_directory (DEBUGDIR,
                         DEBUGDIR_RELOCATABLE);

  gdb_datadir = relocate_gdb_directory (GDB_DATADIR,
                    GDB_DATADIR_RELOCATABLE);

But those values were not set correctly, so I need to hack the path under MinGW.

It is quite simple to test whether GDB set the python path correctly, just run:

python print gdb.PYTHONDIR

If it shows the correct path, then it's good.

PS: I will have a travel in two days, so further response from me will be some bit later.

asmwarrior
ollydbg from codeblocks' forum

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Thu, 12 Jan 2012 08:16:44 +0800
> From: asmwarrior <asmwarrior@gmail.com>
> CC: gdb-patches@sourceware.org
> 
> I have just look at my notes half years ago(no time to write a complete session right now), the issue is:
> In the file:
> 
> build\gdb\config.status
> 
> The value is hard-coded:
> 
> D["DEBUGDIR"]=" \"/mingw/lib/debug\""
> D["DEBUGDIR_RELOCATABLE"]=" 1"
> D["GDB_DATADIR"]=" \"/mingw/share/gdb\""

This is not hard-coded, this comes from the --prefix argument you
passed to the configure script.  In my config.status it shows the
correct directory.

There's a problem loosely related to the MinGW build, whereby it is
customary on MS-Windows to move the built binaries to another machine,
e.g. if one downloads pre-built binaries from some site, like the
MinGW site.  If the --prefix value used by whoever built the package
does not fit the end-user's filesystem and/or the top-level directory
under which the binary distro is unpacked, then things will not work.

So I think in the long run it would be a Good Thing for GDB to try to
look for its data files relative to the place where the executable is
installed, and not only on Windows.  But that is a separate project;
at least I would love to see patches along these lines.

> It is quite simple to test whether GDB set the python path correctly, just run:
> 
> python print gdb.PYTHONDIR
> 
> If it shows the correct path, then it's good.

The above works correctly for me in the GDB I just built with MinGW.

Re: Building GDB 7.3.92 with MinGW

[Joel Brobecker]

> So I think in the long run it would be a Good Thing for GDB to try to
> look for its data files relative to the place where the executable is
> installed, and not only on Windows.  But that is a separate project;
> at least I would love to see patches along these lines.

I think we already, unless I misunderstood what you are trying to say.
Every night, we build GDB on one Windows machine and then test it on
all other Windows machines we have, using a different install prefix.
GDB seems to be able to find all auxilary files without problem.

The only case when path "relocation" is turned off is when the user
configured directories such as the gdb-datadir using a path that is
not a subdir of the prefix.

-- 
Joel

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Thu, 12 Jan 2012 10:47:21 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: asmwarrior <asmwarrior@gmail.com>, dje@google.com,	gdb-patches@sourceware.org
> 
> > So I think in the long run it would be a Good Thing for GDB to try to
> > look for its data files relative to the place where the executable is
> > installed, and not only on Windows.  But that is a separate project;
> > at least I would love to see patches along these lines.
> 
> I think we already, unless I misunderstood what you are trying to say.
> Every night, we build GDB on one Windows machine and then test it on
> all other Windows machines we have, using a different install prefix.
> GDB seems to be able to find all auxilary files without problem.
> 
> The only case when path "relocation" is turned off is when the user
> configured directories such as the gdb-datadir using a path that is
> not a subdir of the prefix.

That latter case is what I had in mind.  In general, it is a bad mojo
to force Windows users to install binaries in some specific tree or
under a certain parent directory.  E.g., the binary could be
configured for d:/usr as a prefix, but installed in c:/foo/bar.

Re: Building GDB 7.3.92 with MinGW

[Joel Brobecker]

> > The only case when path "relocation" is turned off is when the user
> > configured directories such as the gdb-datadir using a path that is
> > not a subdir of the prefix.
> 
> That latter case is what I had in mind.  In general, it is a bad mojo
> to force Windows users to install binaries in some specific tree or
> under a certain parent directory.  E.g., the binary could be
> configured for d:/usr as a prefix, but installed in c:/foo/bar.

This is not what I meant, or did I misunderstand you.

Here is what I am trying to say. It is perfectly fine to do:

  % /path/to/gdb/configure --prefix=c:/usr/my-gdb
  % make
  % make install
  % cp -R c:/usr/my-gdb c:/foo/bar

Relocations should still be working, and our own experience with
that reveals no obvious problem.

What I am saying is the following configure command will turn
gdb-datadir relocation off:

  % /path/to/gdb/configure --prefix=c:/usr --with-gdbdatadir=c:/foo

This is because c:/foo is not "inside" c:/usr.  On other other hand,
datadir relocation would still be active if --with-gdbdatadir was
c:/usr/share/gdb-datadir.

-- 
Joel

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Thu, 12 Jan 2012 15:53:55 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: asmwarrior@gmail.com, dje@google.com, gdb-patches@sourceware.org
> 
> > > The only case when path "relocation" is turned off is when the user
> > > configured directories such as the gdb-datadir using a path that is
> > > not a subdir of the prefix.
> > 
> > That latter case is what I had in mind.  In general, it is a bad mojo
> > to force Windows users to install binaries in some specific tree or
> > under a certain parent directory.  E.g., the binary could be
> > configured for d:/usr as a prefix, but installed in c:/foo/bar.
> 
> This is not what I meant, or did I misunderstand you.

No, the misunderstanding is all mine.  Sorry.

> Here is what I am trying to say. It is perfectly fine to do:
> 
>   % /path/to/gdb/configure --prefix=c:/usr/my-gdb
>   % make
>   % make install
>   % cp -R c:/usr/my-gdb c:/foo/bar
> 
> Relocations should still be working, and our own experience with
> that reveals no obvious problem.

Then I guess asmwarrior should try to find out why it doesn't work for
him.

Re: Building GDB 7.3.92 with MinGW

[asmwarrior]

On 2012-1-13 0:53, Eli Zaretskii wrote:
>> Here is what I am trying to say. It is perfectly fine to do:
>> >
>> >     % /path/to/gdb/configure --prefix=c:/usr/my-gdb
>> >     % make
>> >     % make install
>> >     % cp -R c:/usr/my-gdb c:/foo/bar
>> >
>> >  Relocations should still be working, and our own experience with
>> >  that reveals no obvious problem.
> Then I guess asmwarrior should try to find out why it doesn't work for
> him.
>

I did exactly the same thing as Joel said, but NO luck here.
(I debugged this issue in August 2011 for several days)

1, I build gdb under MSYS+MinGW, and the configure command has the Linux style path like:

../gdb/configure --prefix=/c/user/my-gdb

gdb can not find the python automatically.

2, I just test the official mingw-gdb (with python enabled), gdb can't relocate the "shared" path either.

3, here is what I did to check whether it works:

a, suppose you have gdb install or copied in some folder:
c:/path_to_mingw/bin/gdb.exe
c:/path_to_mingw/share/gdb/python/gdb (this folder contains some python script like:printing.py....)

b, run the gdb.exe.
b1, you can type:
python print gdb.PYTHONDIR
It should return the windows path: c:/path_to_mingw/share/gdb/python

b2, you can continue type:
info pretty-printer
Then, gdb will report all the pretty-printers installed. If you encountered some error message like:
Undefined info command: "pretty-printer".  Try "help info".
This means gdb's own python script does not loaded correctly when gdb startup, this is because gdb can't find the path:
c:/path_to_mingw/share/gdb/python/gdb

So, Joel, can you just test the steps I described above? Both step a, and step b, b1, b2.

With my hacky patch I posted in this thread some days ago, my gdb.exe can works OK wherever the "path_to_mingw" put, so it is relocated.

asmwarrior
ollydbg from codeblocks' forum

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Fri, 13 Jan 2012 22:13:52 +0800
> From: asmwarrior <asmwarrior@gmail.com>
> CC: Joel Brobecker <brobecker@adacore.com>, dje@google.com, 
>  gdb-patches@sourceware.org
> 
> a, suppose you have gdb install or copied in some folder:
> c:/path_to_mingw/bin/gdb.exe
> c:/path_to_mingw/share/gdb/python/gdb (this folder contains some python script like:printing.py....)
> 
> b, run the gdb.exe.
> b1, you can type:
> python print gdb.PYTHONDIR
> It should return the windows path: c:/path_to_mingw/share/gdb/python

Works for me.

> b2, you can continue type:
> info pretty-printer
> Then, gdb will report all the pretty-printers installed. If you encountered some error message like:
> Undefined info command: "pretty-printer".  Try "help info".
> This means gdb's own python script does not loaded correctly when gdb startup, this is because gdb can't find the path:
> c:/path_to_mingw/share/gdb/python/gdb

What does it mean if "info pretty-printer" doesn't display anything,
but doesn't show any error messages, either?

Re: Building GDB 7.3.92 with MinGW

[asmwarrior]

On 2012-1-13 23:48, Eli Zaretskii wrote:
>> Date: Fri, 13 Jan 2012 22:13:52 +0800
>> From: asmwarrior<asmwarrior@gmail.com>
>> CC: Joel Brobecker<brobecker@adacore.com>,dje@google.com,
>>   gdb-patches@sourceware.org
>>
>> a, suppose you have gdb install or copied in some folder:
>> c:/path_to_mingw/bin/gdb.exe
>> c:/path_to_mingw/share/gdb/python/gdb (this folder contains some python script like:printing.py....)
>>
>> b, run the gdb.exe.
>> b1, you can type:
>> python print gdb.PYTHONDIR
>> It should return the windows path: c:/path_to_mingw/share/gdb/python
> Works for me.
I test it again today, and it does not works on my XP.
The official MinGW-gdb is build with such configure option(like my personal build):
           CFLAGS="-O2 -fno-omit-frame-pointer -mtune=i686" \
           ../gdb-7.3.1/configure \
           --program-suffix="-python27" \
           --prefix=/mingw \
           --host=mingw32 \
           --build=mingw32 \
           --target=mingw32 \
           --with-python=/python/python \
           --with-expat

When you put the MinGW in some different folders in the driver E:
like e:/mymingw1  and e:/mymingw2

When you run gdb and enter: python print gdb.PYTHONDIR, it will always return:
e:\mingw\share\gdb/python
You see, I have no such path here in dirver e.
I'm not sure how you test your gdb, did you just put you MinGW under e:/MinGW? Can you try some other places?

>
>> b2, you can continue type:
>> info pretty-printer
>> Then, gdb will report all the pretty-printers installed. If you encountered some error message like:
>> Undefined info command: "pretty-printer".  Try "help info".
>> This means gdb's own python script does not loaded correctly when gdb startup, this is because gdb can't find the path:
>> c:/path_to_mingw/share/gdb/python/gdb
> What does it mean if "info pretty-printer" doesn't display anything,
> but doesn't show any error messages, either?
If you don't have any pretty-printers installed, but gdb's own python script loaded correctly.
you will have nothing returned from gdb, like:
(gdb) info pretty-printer [ENTER HERE]
(gdb)

asmwarrior
ollydbg from codeblocks' forum

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Sat, 14 Jan 2012 20:55:15 +0800
> From: asmwarrior <asmwarrior@gmail.com>
> CC: brobecker@adacore.com, dje@google.com, gdb-patches@sourceware.org
> 
> On 2012-1-13 23:48, Eli Zaretskii wrote:
> >> Date: Fri, 13 Jan 2012 22:13:52 +0800
> >> From: asmwarrior<asmwarrior@gmail.com>
> >> CC: Joel Brobecker<brobecker@adacore.com>, dje@google.com,
> >>   gdb-patches@sourceware.org
> >>
> >> a, suppose you have gdb install or copied in some folder:
> >> c:/path_to_mingw/bin/gdb.exe
> >> c:/path_to_mingw/share/gdb/python/gdb (this folder contains some python script like:printing.py....)
> >>
> >> b, run the gdb.exe.
> >> b1, you can type:
> >> python print gdb.PYTHONDIR
> >> It should return the windows path: c:/path_to_mingw/share/gdb/python
> > Works for me.
> I test it again today, and it does not works on my XP.

What does it mean "does not work", in your case?

> The official MinGW-gdb is build with such configure option(like my personal build):
>            CFLAGS="-O2 -fno-omit-frame-pointer -mtune=i686" \
>            ../gdb-7.3.1/configure \
>            --program-suffix="-python27" \
>            --prefix=/mingw \
>            --host=mingw32 \
>            --build=mingw32 \
>            --target=mingw32 \
>            --with-python=/python/python \
>            --with-expat
> 
> When you put the MinGW in some different folders in the driver E:
> like e:/mymingw1  and e:/mymingw2
> 
> When you run gdb and enter: python print gdb.PYTHONDIR, it will always return:
> e:\mingw\share\gdb/python
> You see, I have no such path here in dirver e.
> I'm not sure how you test your gdb, did you just put you MinGW under e:/MinGW? Can you try some other places?

Are you saying that the problem happens only if the directory
configured as --prefix does not exist at all on the machine where you
run GDB?

RE: Building GDB 7.3.92 with MinGW

[Pierre Muller]

  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

Re: Building GDB 7.3.92 with MinGW

[asmwarrior]

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

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Cc: <brobecker@adacore.com>, <dje@google.com>, <gdb-patches@sourceware.org>
> Date: Sat, 14 Jan 2012 23:32:10 +0100
> 
>   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).

This might explain how it works for me: I manually edit config.h to
convert MSYS file names to native Windows ones, before building GDB.

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.

>   I do believe that this is an error in the mingw32 configuration
> and that it should be fixed in those configuration files...

A simple Sed script will do, but it must be injected into the
configure script.

Alternatively, did you try to use MinGW file names in --prefix when
configuring in the first place?

Re: Building GDB 7.3.92 with MinGW

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2304 bytes --]

> This might explain how it works for me: I manually edit config.h to
> convert MSYS file names to native Windows ones, before building GDB.

This should not be necessary.

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.

I said "I think" because the environment was setup for me, and it just
worked, so I never looked into this further.

Naively, I thought that it would have worked anyways if GDB was
configured with an MSYS-only path. I just don't know enough about
the whole process to understand what happened without debugging
myself. I am wondering whether, maybe, the configure script is auto-
computing some paths that, textually, do not look like a subdirectory
of the prefix.

> 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). In fact, why don't you and Pierre send your gdb/config.h file
for us to inspect. Attached is mine.

> Alternatively, did you try to use MinGW file names in --prefix when
> configuring in the first place?

That's what we do. I missed this part of your reply when I started
writing mine. The "trick" is to provide a directory name that both
MinGW and MSYS understand (I am not really sure why this is necessary).

-- 
Joel

[-- Attachment #2: x86-windows-config.h --]
[-- Type: text/x-chdr, Size: 30372 bytes --]

/* config.h.  Generated from config.in by configure.  */
/* config.in.  Generated from configure.ac by autoheader.  */

/* Define if the compiler is building for multiple architectures of Apple
   platforms at once. */
/* #undef AA_APPLE_UNIVERSAL_BUILD */

/* Define if building universal (internal helper macro) */
/* #undef AC_APPLE_UNIVERSAL_BUILD */

/* Define to the number of bits in type 'ptrdiff_t'. */
/* #undef BITSIZEOF_PTRDIFF_T */

/* Define to the number of bits in type 'sig_atomic_t'. */
/* #undef BITSIZEOF_SIG_ATOMIC_T */

/* Define to the number of bits in type 'size_t'. */
/* #undef BITSIZEOF_SIZE_T */

/* Define to the number of bits in type 'wchar_t'. */
/* #undef BITSIZEOF_WCHAR_T */

/* Define to the number of bits in type 'wint_t'. */
/* #undef BITSIZEOF_WINT_T */

/* Define to 1 if the compiler supports long long. */
#define CC_HAS_LONG_LONG 1

/* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP
   systems. This function is required for `alloca.c' support on those systems.
   */
/* #undef CRAY_STACKSEG_END */

/* Define to 1 if using `alloca.c'. */
/* #undef C_ALLOCA */

/* look for global separate debug info in this path [LIBDIR/debug] */
#define DEBUGDIR "/usr/lib/debug"

/* Define if the separate-debug-dir directory should be relocated when GDB is
   moved. */
#define DEBUGDIR_RELOCATABLE 0

/* Define to BFD's default architecture. */
#define DEFAULT_BFD_ARCH bfd_i386_arch

/* Define to BFD's default target vector. */
#define DEFAULT_BFD_VEC i386pe_vec

/* Define to 1 if translation of program messages to the user's native
   language is requested. */
/* #undef ENABLE_NLS */

/* look for global separate data files in this path [DATADIR/gdb] */
#define GDB_DATADIR "/gnu/gdb-7.3/install/share/gdb-7.3"

/* Define if the gdb-datadir directory should be relocated when GDB is moved.
   */
#define GDB_DATADIR_RELOCATABLE 1

/* Define to be a string naming the default host character set. */
#define GDB_DEFAULT_HOST_CHARSET "UTF-8"

/* Host double floatformat */
#define GDB_HOST_DOUBLE_FORMAT &floatformat_ieee_double_little

/* Host float floatformat */
#define GDB_HOST_FLOAT_FORMAT &floatformat_ieee_single_little

/* Host long double floatformat */
#define GDB_HOST_LONG_DOUBLE_FORMAT &floatformat_i387_ext

/* nativefile */
/* #undef GDB_NM_FILE */

/* Define to the default OS ABI for this configuration. */
#define GDB_OSABI_DEFAULT GDB_OSABI_CYGWIN

/* Define to 1 when the gnulib module memchr should be tested. */
#define GNULIB_TEST_MEMCHR 1

/* Define to 1 when the gnulib module memmem should be tested. */
#define GNULIB_TEST_MEMMEM 1

/* Define to 1 if you have `alloca', as a function or macro. */
#define HAVE_ALLOCA 1

/* Define to 1 if you have <alloca.h> and it should be used (not on Ultrix).
   */
/* #undef HAVE_ALLOCA_H */

/* Define to 1 if you have the <bp-sym.h> header file. */
/* #undef HAVE_BP_SYM_H */

/* Define to 1 if you have the `btowc' function. */
#define HAVE_BTOWC 1

/* Define to 1 if you have the `canonicalize_file_name' function. */
/* #undef HAVE_CANONICALIZE_FILE_NAME */

/* Define to 1 if you have the <ctype.h> header file. */
#define HAVE_CTYPE_H 1

/* Define to 1 if you have the <cursesX.h> header file. */
/* #undef HAVE_CURSESX_H */

/* Define to 1 if you have the <curses.h> header file. */
/* #undef HAVE_CURSES_H */

/* Define to 1 if you have the declaration of `ADDR_NO_RANDOMIZE', and to 0 if
   you don't. */
#define HAVE_DECL_ADDR_NO_RANDOMIZE 0

/* Define to 1 if you have the declaration of `free', and to 0 if you don't.
   */
#define HAVE_DECL_FREE 1

/* Define to 1 if you have the declaration of `getopt', and to 0 if you don't.
   */
#define HAVE_DECL_GETOPT 1

/* Define to 1 if you have the declaration of `getthrds', and to 0 if you
   don't. */
/* #undef HAVE_DECL_GETTHRDS */

/* Define to 1 if you have the declaration of `malloc', and to 0 if you don't.
   */
#define HAVE_DECL_MALLOC 1

/* Define to 1 if you have the declaration of `memmem', and to 0 if you don't.
   */
#define HAVE_DECL_MEMMEM 0

/* Define to 1 if you have the declaration of `ptrace', and to 0 if you don't.
   */
#define HAVE_DECL_PTRACE 0

/* Define to 1 if you have the declaration of `realloc', and to 0 if you
   don't. */
#define HAVE_DECL_REALLOC 1

/* Define to 1 if you have the declaration of `snprintf', and to 0 if you
   don't. */
#define HAVE_DECL_SNPRINTF 1

/* Define to 1 if you have the declaration of `strerror', and to 0 if you
   don't. */
#define HAVE_DECL_STRERROR 1

/* Define to 1 if you have the declaration of `strstr', and to 0 if you don't.
   */
#define HAVE_DECL_STRSTR 1

/* Define to 1 if you have the declaration of `vsnprintf', and to 0 if you
   don't. */
#define HAVE_DECL_VSNPRINTF 1

/* Define to 1 if you have the <dirent.h> header file, and it defines `DIR'.
   */
#define HAVE_DIRENT_H 1

/* Define if ELF support should be included. */
#define HAVE_ELF 1

/* Define to 1 if you have the <elf_hp.h> header file. */
/* #undef HAVE_ELF_HP_H */

/* Define to 1 if your system has the etext variable. */
/* #undef HAVE_ETEXT */

/* Define to 1 if you have the `fork' function. */
/* #undef HAVE_FORK */

/* Define if <sys/procfs.h> has fpregset_t. */
/* #undef HAVE_FPREGSET_T */

/* Define to 1 if you have the `getgid' function. */
/* #undef HAVE_GETGID */

/* Define to 1 if you have the `getpagesize' function. */
#define HAVE_GETPAGESIZE 1

/* Define to 1 if you have the `getrlimit' function. */
/* #undef HAVE_GETRLIMIT */

/* Define to 1 if you have the `getrusage' function. */
/* #undef HAVE_GETRUSAGE */

/* Define to 1 if you have the `getuid' function. */
/* #undef HAVE_GETUID */

/* Define to 1 if you have the <gnu/libc-version.h> header file. */
/* #undef HAVE_GNU_LIBC_VERSION_H */

/* Define if <sys/procfs.h> has gregset_t. */
/* #undef HAVE_GREGSET_T */

/* Define if you have the iconv() function. */
#define HAVE_ICONV 1

/* Define to 1 if you have the `iconvlist' function. */
/* #undef HAVE_ICONVLIST */

/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1

/* Define if you have <langinfo.h> and nl_langinfo(CODESET). */
/* #undef HAVE_LANGINFO_CODESET */

/* Define if your <locale.h> file defines LC_MESSAGES. */
/* #undef HAVE_LC_MESSAGES */

/* Define to 1 if you have the `dl' library (-ldl). */
/* #undef HAVE_LIBDL */

/* Define if you have the expat library. */
#define HAVE_LIBEXPAT 1

/* Define to 1 if you have the `libiconvlist' function. */
#define HAVE_LIBICONVLIST 1

/* Define to 1 if you have the `m' library (-lm). */
#define HAVE_LIBM 1

/* Define if Python 2.4 is being used. */
/* #undef HAVE_LIBPYTHON2_4 */

/* Define if Python 2.5 is being used. */
/* #undef HAVE_LIBPYTHON2_5 */

/* Define if Python 2.6 is being used. */
/* #undef HAVE_LIBPYTHON2_6 */

/* Define if Python 2.7 is being used. */
#define HAVE_LIBPYTHON2_7 1

/* Define if libunwind library is being used. */
/* #undef HAVE_LIBUNWIND */

/* Define if GDB is to be linked against libunwind. The default method is to
   use dlopen() to access this shared library. */
/* #undef HAVE_LIBUNWIND_DIRECT_ACCESS */

/* Define to 1 if you have the <libunwind.h> header file. */
/* #undef HAVE_LIBUNWIND_H */

/* Define to 1 if you have the <libunwind-ia64.h> header file. */
/* #undef HAVE_LIBUNWIND_IA64_H */

/* Define if you have the usb library. */
/* #undef HAVE_LIBUSB */

/* Define to 1 if you have the `w' library (-lw). */
/* #undef HAVE_LIBW */

/* Define to 1 if you have the <link.h> header file. */
/* #undef HAVE_LINK_H */

/* Define to 1 if you have the <locale.h> header file. */
#define HAVE_LOCALE_H 1

/* Define to 1 if the compiler supports long double. */
#define HAVE_LONG_DOUBLE 1

/* Define to 1 if the system has the type `long long int'. */
#define HAVE_LONG_LONG_INT 1

/* Define if <sys/procfs.h> has lwpid_t. */
/* #undef HAVE_LWPID_T */

/* Define to 1 if you have the <machine/reg.h> header file. */
/* #undef HAVE_MACHINE_REG_H */

/* Define to 1 if mmap()'s MAP_ANONYMOUS flag is available after including
   config.h and <sys/mman.h>. */
/* #undef HAVE_MAP_ANONYMOUS */

/* Define to 1 if you have the `memchr' function. */
#define HAVE_MEMCHR 1

/* Define to 1 if you have the `memmem' function. */
/* #undef HAVE_MEMMEM */

/* Define to 1 if you have the <memory.h> header file. */
#define HAVE_MEMORY_H 1

/* Define to 1 if you have a working `mmap' system call. */
/* #undef HAVE_MMAP */

/* Define to 1 if you have the `monstartup' function. */
/* #undef HAVE_MONSTARTUP */

/* Define to 1 if you have the `mprotect' function. */
#define HAVE_MPROTECT 1

/* Define to 1 if you have the <ncurses.h> header file. */
/* #undef HAVE_NCURSES_H */

/* Define to 1 if you have the <ncurses/ncurses.h> header file. */
/* #undef HAVE_NCURSES_NCURSES_H */

/* Define to 1 if you have the <ncurses/term.h> header file. */
/* #undef HAVE_NCURSES_TERM_H */

/* Define to 1 if you have the <ndir.h> header file, and it defines `DIR'. */
/* #undef HAVE_NDIR_H */

/* Define to 1 if you have the <nlist.h> header file. */
/* #undef HAVE_NLIST_H */

/* Define if you support the personality syscall. */
/* #undef HAVE_PERSONALITY */

/* Define to 1 if you have the `pipe' function. */
/* #undef HAVE_PIPE */

/* Define to 1 if you have the `poll' function. */
/* #undef HAVE_POLL */

/* Define to 1 if you have the <poll.h> header file. */
/* #undef HAVE_POLL_H */

/* Define to 1 if you have the `posix_madvise' function. */
/* #undef HAVE_POSIX_MADVISE */

/* Define to 1 if you have the `pread64' function. */
/* #undef HAVE_PREAD64 */

/* Define if <sys/procfs.h> has prfpregset32_t. */
/* #undef HAVE_PRFPREGSET32_T */

/* Define if <sys/procfs.h> has prfpregset_t. */
/* #undef HAVE_PRFPREGSET_T */

/* Define if <sys/procfs.h> has prgregset32_t. */
/* #undef HAVE_PRGREGSET32_T */

/* Define if <sys/procfs.h> has prgregset_t. */
/* #undef HAVE_PRGREGSET_T */

/* Define if ioctl argument PIOCSET is available. */
/* #undef HAVE_PROCFS_PIOCSET */

/* Define to 1 if you have the <proc_service.h> header file. */
/* #undef HAVE_PROC_SERVICE_H */

/* Define if <sys/procfs.h> has prrun_t. */
/* #undef HAVE_PRRUN_T */

/* Define if <sys/procfs.h> has prsysent_t. */
/* #undef HAVE_PRSYSENT_T */

/* Define if <sys/procfs.h> has pr_sigaction64_t. */
/* #undef HAVE_PR_SIGACTION64_T */

/* Define if <sys/procfs.h> has pr_siginfo64_t. */
/* #undef HAVE_PR_SIGINFO64_T */

/* Define if <sys/procfs.h> has pr_sigset_t. */
/* #undef HAVE_PR_SIGSET_T */

/* Define if <sys/procfs.h> has psaddr_t. */
/* #undef HAVE_PSADDR_T */

/* Define if <sys/procfs.h> has pstatus_t. */
/* #undef HAVE_PSTATUS_T */

/* Define if sys/ptrace.h defines the PTRACE_GETFPXREGS request. */
/* #undef HAVE_PTRACE_GETFPXREGS */

/* Define if sys/ptrace.h defines the PTRACE_GETREGS request. */
/* #undef HAVE_PTRACE_GETREGS */

/* Define to 1 if you have the <ptrace.h> header file. */
/* #undef HAVE_PTRACE_H */

/* Define if sys/ptrace.h defines the PT_GETDBREGS request. */
/* #undef HAVE_PT_GETDBREGS */

/* Define if sys/ptrace.h defines the PT_GETXMMREGS request. */
/* #undef HAVE_PT_GETXMMREGS */

/* Define if Python interpreter is being linked in. */
#define HAVE_PYTHON 1

/* Define to 1 if btowc is declared even after undefining macros. */
#define HAVE_RAW_DECL_BTOWC 1

/* Define to 1 if mbrlen is declared even after undefining macros. */
#define HAVE_RAW_DECL_MBRLEN 1

/* Define to 1 if mbrtowc is declared even after undefining macros. */
#define HAVE_RAW_DECL_MBRTOWC 1

/* Define to 1 if mbsinit is declared even after undefining macros. */
#define HAVE_RAW_DECL_MBSINIT 1

/* Define to 1 if mbsnrtowcs is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_MBSNRTOWCS */

/* Define to 1 if mbsrtowcs is declared even after undefining macros. */
#define HAVE_RAW_DECL_MBSRTOWCS 1

/* Define to 1 if memmem is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_MEMMEM */

/* Define to 1 if mempcpy is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_MEMPCPY */

/* Define to 1 if memrchr is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_MEMRCHR */

/* Define to 1 if rawmemchr is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_RAWMEMCHR */

/* Define to 1 if stpcpy is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_STPCPY */

/* Define to 1 if stpncpy is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_STPNCPY */

/* Define to 1 if strcasestr is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_STRCASESTR */

/* Define to 1 if strchrnul is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_STRCHRNUL */

/* Define to 1 if strdup is declared even after undefining macros. */
#define HAVE_RAW_DECL_STRDUP 1

/* Define to 1 if strncat is declared even after undefining macros. */
#define HAVE_RAW_DECL_STRNCAT 1

/* Define to 1 if strndup is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_STRNDUP */

/* Define to 1 if strnlen is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_STRNLEN */

/* Define to 1 if strpbrk is declared even after undefining macros. */
#define HAVE_RAW_DECL_STRPBRK 1

/* Define to 1 if strsep is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_STRSEP */

/* Define to 1 if strsignal is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_STRSIGNAL */

/* Define to 1 if strtok_r is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_STRTOK_R */

/* Define to 1 if strverscmp is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_STRVERSCMP */

/* Define to 1 if wcrtomb is declared even after undefining macros. */
#define HAVE_RAW_DECL_WCRTOMB 1

/* Define to 1 if wcsnrtombs is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_WCSNRTOMBS */

/* Define to 1 if wcsrtombs is declared even after undefining macros. */
#define HAVE_RAW_DECL_WCSRTOMBS 1

/* Define to 1 if wctob is declared even after undefining macros. */
#define HAVE_RAW_DECL_WCTOB 1

/* Define to 1 if wcwidth is declared even after undefining macros. */
/* #undef HAVE_RAW_DECL_WCWIDTH */

/* Define to 1 if you have the `realpath' function. */
/* #undef HAVE_REALPATH */

/* Define to 1 if you have the `resize_term' function. */
/* #undef HAVE_RESIZE_TERM */

/* Define to 1 if you have the `sbrk' function. */
/* #undef HAVE_SBRK */

/* Define to 1 if you have the `setlocale' function. */
#define HAVE_SETLOCALE 1

/* Define to 1 if you have the `setpgid' function. */
/* #undef HAVE_SETPGID */

/* Define to 1 if you have the `setpgrp' function. */
/* #undef HAVE_SETPGRP */

/* Define to 1 if you have the `setrlimit' function. */
/* #undef HAVE_SETRLIMIT */

/* Define to 1 if you have the `setsid' function. */
/* #undef HAVE_SETSID */

/* Define to 1 if you have the <sgtty.h> header file. */
/* #undef HAVE_SGTTY_H */

/* Define to 1 if you have the `sigaction' function. */
/* #undef HAVE_SIGACTION */

/* Define to 1 if you have the <signal.h> header file. */
#define HAVE_SIGNAL_H 1

/* Define to 1 if 'sig_atomic_t' is a signed integer type. */
/* #undef HAVE_SIGNED_SIG_ATOMIC_T */

/* Define to 1 if 'wchar_t' is a signed integer type. */
/* #undef HAVE_SIGNED_WCHAR_T */

/* Define to 1 if 'wint_t' is a signed integer type. */
/* #undef HAVE_SIGNED_WINT_T */

/* Define to 1 if you have the `sigprocmask' function. */
/* #undef HAVE_SIGPROCMASK */

/* Define if sigsetjmp is available. */
/* #undef HAVE_SIGSETJMP */

/* Define to 1 if you have the `sigsetmask' function. */
/* #undef HAVE_SIGSETMASK */

/* Define to 1 if you have the `socketpair' function. */
/* #undef HAVE_SOCKETPAIR */

/* Define to 1 if the system has the type `socklen_t'. */
/* #undef HAVE_SOCKLEN_T */

/* Define if we have IRIX 6 pthread debugging support. */
/* #undef HAVE_SPYTHREAD */

/* Define to 1 if you have the <stddef.h> header file. */
#define HAVE_STDDEF_H 1

/* Define to 1 if you have the <stdint.h> header file. */
#define HAVE_STDINT_H 1

/* Define to 1 if you have the <stdlib.h> header file. */
#define HAVE_STDLIB_H 1

/* Define to 1 if you have the <strings.h> header file. */
#define HAVE_STRINGS_H 1

/* Define to 1 if you have the <string.h> header file. */
#define HAVE_STRING_H 1

/* Define if <sys/link.h> has struct link_map32 */
/* #undef HAVE_STRUCT_LINK_MAP32 */

/* Define if <link.h> exists and defines struct link_map which has members
   with an ``lm_'' prefix. (For SunOS.) */
/* #undef HAVE_STRUCT_LINK_MAP_WITH_LM_MEMBERS */

/* Define if <link.h> exists and defines struct link_map which has members
   with an ``l_'' prefix. (For Solaris, SVR4, and SVR4-like systems.) */
/* #undef HAVE_STRUCT_LINK_MAP_WITH_L_MEMBERS */

/* Define to 1 if your system has struct lwp. */
/* #undef HAVE_STRUCT_LWP */

/* Define to 1 if your system has struct reg in <machine/reg.h>. */
/* #undef HAVE_STRUCT_REG */

/* Define to 1 if `struct reg' is a member of `r_fs'. */
/* #undef HAVE_STRUCT_REG_R_FS */

/* Define to 1 if `struct reg' is a member of `r_gs'. */
/* #undef HAVE_STRUCT_REG_R_GS */

/* Define if <link.h> exists and defines a struct so_map which has members
   with an ``som_'' prefix. (Found on older *BSD systems.) */
/* #undef HAVE_STRUCT_SO_MAP_WITH_SOM_MEMBERS */

/* Define to 1 if `struct stat' is a member of `st_blksize'. */
/* #undef HAVE_STRUCT_STAT_ST_BLKSIZE */

/* Define to 1 if `struct stat' is a member of `st_blocks'. */
/* #undef HAVE_STRUCT_STAT_ST_BLOCKS */

/* Define to 1 if `struct thread' is a member of `td_pcb'. */
/* #undef HAVE_STRUCT_THREAD_TD_PCB */

/* Define to 1 if you have the `syscall' function. */
/* #undef HAVE_SYSCALL */

/* Define to 1 if you have the <sys/bitypes.h> header file. */
/* #undef HAVE_SYS_BITYPES_H */

/* Define to 1 if you have the <sys/debugreg.h> header file. */
/* #undef HAVE_SYS_DEBUGREG_H */

/* Define to 1 if you have the <sys/dir.h> header file, and it defines `DIR'.
   */
/* #undef HAVE_SYS_DIR_H */

/* Define to 1 if you have the <sys/fault.h> header file. */
/* #undef HAVE_SYS_FAULT_H */

/* Define to 1 if you have the <sys/file.h> header file. */
#define HAVE_SYS_FILE_H 1

/* Define to 1 if you have the <sys/filio.h> header file. */
/* #undef HAVE_SYS_FILIO_H */

/* Define to 1 if you have the <sys/inttypes.h> header file. */
/* #undef HAVE_SYS_INTTYPES_H */

/* Define to 1 if you have the <sys/ioctl.h> header file. */
/* #undef HAVE_SYS_IOCTL_H */

/* Define to 1 if you have the <sys/mman.h> header file. */
/* #undef HAVE_SYS_MMAN_H */

/* Define to 1 if you have the <sys/ndir.h> header file, and it defines `DIR'.
   */
/* #undef HAVE_SYS_NDIR_H */

/* Define to 1 if you have the <sys/param.h> header file. */
#define HAVE_SYS_PARAM_H 1

/* Define to 1 if you have the <sys/poll.h> header file. */
/* #undef HAVE_SYS_POLL_H */

/* Define to 1 if you have the <sys/procfs.h> header file. */
/* #undef HAVE_SYS_PROCFS_H */

/* Define to 1 if you have the <sys/proc.h> header file. */
/* #undef HAVE_SYS_PROC_H */

/* Define to 1 if you have the <sys/ptrace.h> header file. */
/* #undef HAVE_SYS_PTRACE_H */

/* Define to 1 if you have the <sys/reg.h> header file. */
/* #undef HAVE_SYS_REG_H */

/* Define to 1 if you have the <sys/resource.h> header file. */
/* #undef HAVE_SYS_RESOURCE_H */

/* Define to 1 if you have the <sys/select.h> header file. */
/* #undef HAVE_SYS_SELECT_H */

/* Define to 1 if you have the <sys/stat.h> header file. */
#define HAVE_SYS_STAT_H 1

/* Define to 1 if you have the <sys/syscall.h> header file. */
/* #undef HAVE_SYS_SYSCALL_H */

/* Define to 1 if you have the <sys/types.h> header file. */
#define HAVE_SYS_TYPES_H 1

/* Define to 1 if you have the <sys/user.h> header file. */
/* #undef HAVE_SYS_USER_H */

/* Define to 1 if you have the <sys/wait.h> header file. */
/* #undef HAVE_SYS_WAIT_H */

/* Define to 1 if you have the <termios.h> header file. */
/* #undef HAVE_TERMIOS_H */

/* Define to 1 if you have the <termio.h> header file. */
/* #undef HAVE_TERMIO_H */

/* Define to 1 if you have the <term.h> header file. */
/* #undef HAVE_TERM_H */

/* Define to 1 if you have the <thread_db.h> header file. */
/* #undef HAVE_THREAD_DB_H */

/* Define if using Solaris thread debugging. */
/* #undef HAVE_THREAD_DB_LIB */

/* Define to 1 if you have the <time.h> header file. */
#define HAVE_TIME_H 1

/* Define if you support the tkill syscall. */
/* #undef HAVE_TKILL_SYSCALL */

/* Define to 1 if you have the `ttrace' function. */
/* #undef HAVE_TTRACE */

/* Define to 1 if you have the <unistd.h> header file. */
#define HAVE_UNISTD_H 1

/* Define to 1 if the system has the type `unsigned long long int'. */
#define HAVE_UNSIGNED_LONG_LONG_INT 1

/* Define to 1 if you have the `vfork' function. */
/* #undef HAVE_VFORK */

/* Define to 1 if you have the <vfork.h> header file. */
/* #undef HAVE_VFORK_H */

/* Define to 1 if you have the `waitpid' function. */
/* #undef HAVE_WAITPID */

/* Define to 1 if you have the <wait.h> header file. */
/* #undef HAVE_WAIT_H */

/* Define to 1 if you have the `wborder' function. */
/* #undef HAVE_WBORDER */

/* Define to 1 if you have the <wchar.h> header file. */
#define HAVE_WCHAR_H 1

/* Define if you have the 'wchar_t' type. */
#define HAVE_WCHAR_T 1

/* Define if you have the 'wint_t' type. */
#define HAVE_WINT_T 1

/* Define to 1 if `fork' works. */
/* #undef HAVE_WORKING_FORK */

/* Define to 1 if `vfork' works. */
/* #undef HAVE_WORKING_VFORK */

/* Define to 1 if you have the `wresize' function. */
/* #undef HAVE_WRESIZE */

/* Define to 1 if you have the `XML_StopParser' function. */
#define HAVE_XML_STOPPARSER 1

/* Define to 1 if you have the <zlib.h> header file. */
/* #undef HAVE_ZLIB_H */

/* Define to 1 if your system has the _etext variable. */
/* #undef HAVE__ETEXT */

/* Define to 1 if you have the `_mcleanup' function. */
/* #undef HAVE__MCLEANUP */

/* Define as const if the declaration of iconv() needs const. */
#define ICONV_CONST 

/* Define to a substitute value for mmap()'s MAP_ANONYMOUS flag. */
/* #undef MAP_ANONYMOUS */

/* Define if you want to use new multi-fd /proc interface (replaces
   HAVE_MULTIPLE_PROC_FDS as well as other macros). */
/* #undef NEW_PROC_API */

/* Name of this package. */
#define PACKAGE "gdb"

/* Define to the address where bug reports for this package should be sent. */
#define PACKAGE_BUGREPORT ""

/* Define to the full name of this package. */
#define PACKAGE_NAME ""

/* Define to the full name and version of this package. */
#define PACKAGE_STRING ""

/* Define to the one symbol short name of this package. */
#define PACKAGE_TARNAME ""

/* Define to the home page for this package. */
#define PACKAGE_URL ""

/* Define to the version of this package. */
#define PACKAGE_VERSION ""

/* Additional package description */
#define PKGVERSION "(GDB) "

/* Define if the prfpregset_t type is broken. */
/* #undef PRFPREGSET_T_BROKEN */

/* Define to 1 if the "%H, %D and %DD" formats work to print decfloats. */
/* #undef PRINTF_HAS_DECFLOAT */

/* Define to 1 if the "%Lg" format works to print long doubles. */
#define PRINTF_HAS_LONG_DOUBLE 1

/* Define to 1 if the "%ll" format works to print long longs. */
#define PRINTF_HAS_LONG_LONG 1

/* Define if <proc_service.h> on solaris uses int instead of size_t, and
   assorted other type changes. */
/* #undef PROC_SERVICE_IS_OLD */

/* Define to the type of arg 3 for ptrace. */
#define PTRACE_TYPE_ARG3 long

/* Define to the type of arg 5 for ptrace. */
/* #undef PTRACE_TYPE_ARG5 */

/* Define as the return type of ptrace. */
#define PTRACE_TYPE_RET int

/* Define to l, ll, u, ul, ull, etc., as suitable for constants of type
   'ptrdiff_t'. */
/* #undef PTRDIFF_T_SUFFIX */

/* Define if the python directory should be relocated when GDB is moved. */
#define PYTHON_PATH_RELOCATABLE 1

/* Relocated directory for source files. */
/* #undef RELOC_SRCDIR */

/* Bug reporting address */
#define REPORT_BUGS_TO "<http://www.gnu.org/software/gdb/bugs/>"

/* Define as the return type of signal handlers (`int' or `void'). */
#define RETSIGTYPE void

/* Define to 1 if the "%Lg" format works to scan long doubles. */
/* #undef SCANF_HAS_LONG_DOUBLE */

/* Define to 1 if the `setpgrp' function takes no argument. */
#define SETPGRP_VOID 1

/* Define to l, ll, u, ul, ull, etc., as suitable for constants of type
   'sig_atomic_t'. */
/* #undef SIG_ATOMIC_T_SUFFIX */

/* The size of `long', as computed by sizeof. */
/* #undef SIZEOF_LONG */

/* Define to l, ll, u, ul, ull, etc., as suitable for constants of type
   'size_t'. */
/* #undef SIZE_T_SUFFIX */

/* If using the C implementation of alloca, define if you know the
   direction of stack growth for your system; otherwise it will be
   automatically deduced at runtime.
	STACK_DIRECTION > 0 => grows toward higher addresses
	STACK_DIRECTION < 0 => grows toward lower addresses
	STACK_DIRECTION = 0 => direction of growth unknown */
/* #undef STACK_DIRECTION */

/* Define to 1 if the `S_IS*' macros in <sys/stat.h> do not work properly. */
/* #undef STAT_MACROS_BROKEN */

/* Define to 1 if you have the ANSI C header files. */
#define STDC_HEADERS 1

/* automatically load a system-wide gdbinit file */
#define SYSTEM_GDBINIT ""

/* Define if the system-gdbinit directory should be relocated when GDB is
   moved. */
#define SYSTEM_GDBINIT_RELOCATABLE 0

/* Define if <thread_db.h> has the TD_NOTALLOC error code. */
/* #undef THREAD_DB_HAS_TD_NOTALLOC */

/* Define if <thread_db.h> has the TD_NOTLS error code. */
/* #undef THREAD_DB_HAS_TD_NOTLS */

/* Define if <thread_db.h> has the TD_VERSION error code. */
/* #undef THREAD_DB_HAS_TD_VERSION */

/* Define to 1 if the regex included in libiberty should be used. */
#define USE_INCLUDED_REGEX 1

/* Define if we should use the Windows API, instead of the POSIX API. On
   Windows, we use the Windows API when building for MinGW, but the POSIX API
   when building for Cygwin. */
#define USE_WIN32API 1

/* Define to l, ll, u, ul, ull, etc., as suitable for constants of type
   'wchar_t'. */
/* #undef WCHAR_T_SUFFIX */

/* Define to l, ll, u, ul, ull, etc., as suitable for constants of type
   'wint_t'. */
/* #undef WINT_T_SUFFIX */

/* Define if --with-python provides a path, either directly or via
   python-config.py --exec-prefix. */
#define WITH_PYTHON_PATH "/gnu/gdb-7.3/install/share/gdb-7.3/python-2.7"

/* Define if the simulator is being linked in. */
/* #undef WITH_SIM */

/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
   significant byte first (like Motorola and SPARC, unlike Intel). */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
#  define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
/* #  undef WORDS_BIGENDIAN */
# endif
#endif

/* Number of bits in a file offset, on hosts where this is settable. */
/* #undef _FILE_OFFSET_BITS */

/* Define to 1 so <sys/proc.h> gets a definition of anon_hdl. Works around a
   <sys/proc.h> problem on IRIX 5. */
/* #undef _KMEMUSER */

/* Define for large files, on AIX-style hosts. */
/* #undef _LARGE_FILES */

/* Define to 1 if on MINIX. */
/* #undef _MINIX */

/* Define to 1 to avoid a clash between <widec.h> and <wchar.h> on Solaris
   2.[789] when using GCC. */
/* #undef _MSE_INT_H */

/* Define to 2 if the system does not provide POSIX.1 features except with
   this defined. */
/* #undef _POSIX_1_SOURCE */

/* Define to 1 if you need to in order for `stat' and other things to work. */
/* #undef _POSIX_SOURCE */

/* Define if <sys/link.h> has link_map32 (solaris sparc-64 target) */
/* #undef _SYSCALL32 */

/* Define to 500 only on HP-UX. */
/* #undef _XOPEN_SOURCE */

/* Enable extensions on AIX 3, Interix.  */
#ifndef _ALL_SOURCE
# define _ALL_SOURCE 1
#endif
/* Enable GNU extensions on systems that have them.  */
#ifndef _GNU_SOURCE
# define _GNU_SOURCE 1
#endif
/* Enable threading extensions on Solaris.  */
#ifndef _POSIX_PTHREAD_SEMANTICS
# define _POSIX_PTHREAD_SEMANTICS 1
#endif
/* Enable extensions on HP NonStop.  */
#ifndef _TANDEM_SOURCE
# define _TANDEM_SOURCE 1
#endif
/* Enable general extensions on Solaris.  */
#ifndef __EXTENSIONS__
# define __EXTENSIONS__ 1
#endif


/* Define to empty if `const' does not conform to ANSI C. */
/* #undef const */

/* Define to `__inline__' or `__inline' if that's what the C compiler
   calls it, or to nothing if 'inline' is not supported under any name.  */
#ifndef __cplusplus
/* #undef inline */
#endif

/* Work around a bug in Apple GCC 4.0.1 build 5465: In C99 mode, it supports
   the ISO C 99 semantics of 'extern inline' (unlike the GNU C semantics of
   earlier versions), but does not display it by setting __GNUC_STDC_INLINE__.
   __APPLE__ && __MACH__ test for MacOS X.
   __APPLE_CC__ tests for the Apple compiler and its version.
   __STDC_VERSION__ tests for the C99 mode.  */
#if defined __APPLE__ && defined __MACH__ && __APPLE_CC__ >= 5465 && !defined __cplusplus && __STDC_VERSION__ >= 199901L && !defined __GNUC_STDC_INLINE__
# define __GNUC_STDC_INLINE__ 1
#endif

/* Define to `int' if <sys/types.h> does not define. */
/* #undef pid_t */

/* readline-6.0 started to use different name. */
/* #undef readline_echoing_p */

/* Define to the equivalent of the C99 'restrict' keyword, or to
   nothing if this is not supported.  Do not define if restrict is
   supported directly.  */
#define restrict __restrict
/* Work around a bug in Sun C++: it does not support _Restrict or
   __restrict__, even though the corresponding Sun C compiler ends up with
   "#define restrict _Restrict" or "#define restrict __restrict__" in the
   previous line.  Perhaps some future version of Sun C++ will work with
   restrict; if so, hopefully it defines __RESTRICT like Sun C does.  */
#if defined __SUNPRO_CC && !defined __RESTRICT
# define _Restrict
# define __restrict__
#endif

/* Define as a marker that can be attached to declarations that might not
    be used.  This helps to reduce warnings, such as from
    GCC -Wunused-parameter.  */
#if __GNUC__ >= 3 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 7)
# define _GL_UNUSED __attribute__ ((__unused__))
#else
# define _GL_UNUSED
#endif
/* The name _UNUSED_PARAMETER_ is an earlier spelling, although the name
   is a misnomer outside of parameter lists.  */
#define _UNUSED_PARAMETER_ _GL_UNUSED


/* Define as `fork' if `vfork' does not work. */
#define vfork fork

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Sun, 15 Jan 2012 17:34:27 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>, 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.

RE: Building GDB 7.3.92 with MinGW

[Pierre Muller]

Eli,

  I also wrongly supposed that configure prefix or related entries should
be msys pathes.
  It seems that using directly a mingw32 path for prefix
works well. This allows to get a working relocate_gdb_directory
call in main.c
  Of course, this only works for really existing directories, but 
from what I read in the sources, this was by design.
  A configured directory should only be substituted if the substitute result
is an existing directory.
 
 So I used
  --prefix=e:/pas/fpc-2.6.0
to run configure
ran 'make all install'
and got a first installation in e:\pas\fpc-2.6.0
I then tried 
make install prefix=e:/pas/fpc-2.7.1/gdb
and debugged GDB with itself in e:\pas\fpc-2.7.1\gdb\bin
gdb ./gdb
added a break relocate_gdb_directory
and could check that
e:/pas/fpc-2.6.0/share/gdb
was transformed into 
e:\pas\fpc-2.7.1\gdb\share\gdb


> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Eli Zaretskii
> Envoyé : dimanche 15 janvier 2012 04:55
> À : Pierre Muller
> Cc : asmwarrior@gmail.com; brobecker@adacore.com; dje@google.com; gdb-
> patches@sourceware.org
> Objet : Re: Building GDB 7.3.92 with MinGW
> 
> > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> > Cc: <brobecker@adacore.com>, <dje@google.com>, <gdb-
> patches@sourceware.org>
> > Date: Sat, 14 Jan 2012 23:32:10 +0100
> >
> >   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).
> 
> This might explain how it works for me: I manually edit config.h to
> convert MSYS file names to native Windows ones, before building GDB.

  I also thought that msys system required
real msys pathes to function correctly, but it seems to handle
Mingw32 pathes starting with X:/ correctly also 
which solves the problem.
  I am still surprised that in fact, we really need to do
this in order to get the correct behavior.
 
> 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.
> 
> >   I do believe that this is an error in the mingw32 configuration
> > and that it should be fixed in those configuration files...
> 
> A simple Sed script will do, but it must be injected into the
> configure script.

  That not true in case you really have other mount points
I personally have my different GDB sources located inside cygwin
/usr/local/src
subdirectories, and I also have
 this cygwin /usr/local/src mounted as /usr/local/src on mysys,
which is nice in a way, but leads me to not be able to 
remember in with Windows directory the sources really are ...
 
> Alternatively, did you try to use MinGW file names in --prefix when
> configuring in the first place?
As said above, it seems that this is the right answer!

Pierre Muller

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Cc: <asmwarrior@gmail.com>, <brobecker@adacore.com>, <dje@google.com>,
>         <gdb-patches@sourceware.org>
> Date: Sun, 15 Jan 2012 18:00:51 +0100
> 
>   I also wrongly supposed that configure prefix or related entries should
> be msys pathes.

If the configury supports d:/foo/bar file names (and most modern
versions of Autoconf and libtool do), then using MSYS /d/foo/bar style
of file names is not necessary.  Only of d:/foo fails, you should fall
back on the MSYS style.

>   Of course, this only works for really existing directories, but 
> from what I read in the sources, this was by design.

Yes, sounds like that.  It would be good if GDB could reconfigure its
prefix on the fly, though.

RE: Building GDB 7.3.92 with MinGW

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Eli Zaretskii
> Envoyé : dimanche 15 janvier 2012 19:55
> À : Pierre Muller
> Cc : asmwarrior@gmail.com; brobecker@adacore.com; dje@google.com; gdb-
> patches@sourceware.org
> Objet : Re: Building GDB 7.3.92 with MinGW
> 
> > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> > Cc: <asmwarrior@gmail.com>, <brobecker@adacore.com>, <dje@google.com>,
> >         <gdb-patches@sourceware.org>
> > Date: Sun, 15 Jan 2012 18:00:51 +0100
> >
> >   I also wrongly supposed that configure prefix or related entries
should
> > be msys pathes.
> 
> If the configury supports d:/foo/bar file names (and most modern
> versions of Autoconf and libtool do), then using MSYS /d/foo/bar style
> of file names is not necessary.  Only of d:/foo fails, you should fall
> back on the MSYS style.

  In fact, I think I have now finally found where the problem starts
if you do not specify any --prefix to configure:
  --prefix has a default /usr/local value,
this sets prefix inside gdb/Makefile
  and three directories inside config.h
$ grep 'DIR "' *.h
config.h:#define DEBUGDIR "/usr/local/lib/debug"
config.h:#define GDB_DATADIR "/usr/local/share/gdb"
config.h:#define JIT_READER_DIR "/usr/local/lib/gdb"

But what about BINDIR which is used for reloacate_gdb_directory..
This one is not inside config.h :

$ grep -n -C 3 BINDIR *
Makefile-1520-# Some files need explicit build rules (due to -Werror
problems) or due
Makefile-1521-# to sub-directory fun 'n' games.
Makefile-1522-
Makefile:1523:# main.o needs an explicit build rule to get
TARGET_SYSTEM_ROOT and BINDIR.
Makefile-1524-main.o: $(srcdir)/main.c
Makefile:1525:  $(COMPILE) $(TARGET_SYSTEM_ROOT_DEFINE)
-DBINDIR=\"$(bindir)\" $(srcdir)/main.c
Makefile-1526-  $(POSTCOMPILE)
Makefile-1527-
 
  OK, but defining a macro inside config.h or on command line should 
not make any difference, no?
  The following will prove otherwise!

For testing purpose, I tried to recompile main.o
adding --verbose option to compiler
$ make  main.o CFLAGS="-g -O0 --save-temps --verbose"
make[1]: Entering directory
`/usr/local/src/gdbcvs/mingw32-puresrc-python/gdb'
make[2]: Entering directory
`/usr/local/src/gdbcvs/mingw32-puresrc-python/gdb/gn
ulib'
make  all-recursive
make[3]: Entering directory
`/usr/local/src/gdbcvs/mingw32-puresrc-python/gdb/gn
ulib'
make[4]: Entering directory
`/usr/local/src/gdbcvs/mingw32-puresrc-python/gdb/gn
ulib'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
`/usr/local/src/gdbcvs/mingw32-puresrc-python/gdb/gnu
lib'
make[3]: Leaving directory
`/usr/local/src/gdbcvs/mingw32-puresrc-python/gdb/gnu
lib'
make[2]: Leaving directory
`/usr/local/src/gdbcvs/mingw32-puresrc-python/gdb/gnu
lib'
make[1]: Leaving directory
`/usr/local/src/gdbcvs/mingw32-puresrc-python/gdb'
gcc -g -O0 --save-temps --verbose   -I. -I../../puresrc/gdb
-I../../puresrc/gdb/
common -I../../puresrc/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\""
-DHA
VE_CONFIG_H -I../../puresrc/gdb/../include/opcode
-I../../puresrc/gdb/../opcodes
/.. -I../../puresrc/gdb/../readline/.. -I../bfd -I../../puresrc/gdb/../bfd
-I../
../puresrc/gdb/../include -I../libdecnumber
-I../../puresrc/gdb/../libdecnumber
 -I../../puresrc/gdb/gnulib -Ignulib    -Ic:/Python27/include
-Ic:/Python27/incl
ude -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral
-Wno
-pointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch
-Wno-char
-subscripts -Wno-format -Werror -c -o main.o -MT main.o -MMD -MP -MF
.deps/main.
Tpo -DTARGET_SYSTEM_ROOT=\"\" -DTARGET_SYSTEM_ROOT_RELOCATABLE=0
-DBINDIR=\"/usr
/local/bin\" ../../puresrc/gdb/main.c
Using built-in specs.
COLLECT_GCC=E:\msys\mingw32\bin\gcc.exe
COLLECT_LTO_WRAPPER=e:/msys/mingw32/bin/../libexec/gcc/mingw32/4.6.1/lto-wra
pper
.exe
Target: mingw32
Configured with: ../gcc-4.6.1/configure
--enable-languages=c,c++,fortran,objc,ob
j-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared
--enable-libgomp -
-disable-win32-registry --enable-libstdcxx-debug
--enable-version-specific-runti
me-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.1 (GCC)
COLLECT_GCC_OPTIONS='-g' '-O0' '-save-temps' '-v' '-I' '.' '-I'
'../../puresrc/g
db' '-I' '../../puresrc/gdb/common' '-I' '../../puresrc/gdb/config' '-D'
'LOCALE
DIR="E:/msys/mingw32/msys/1.0/local/share/locale"' '-D' 'HAVE_CONFIG_H' '-I'
'..
/../puresrc/gdb/../include/opcode' '-I' '../../puresrc/gdb/../opcodes/..'
'-I' '
../../puresrc/gdb/../readline/..' '-I' '../bfd' '-I'
'../../puresrc/gdb/../bfd'
'-I' '../../puresrc/gdb/../include' '-I' '../libdecnumber' '-I'
'../../puresrc/g
db/../libdecnumber' '-I' '../../puresrc/gdb/gnulib' '-I' 'gnulib' '-I'
'c:/Pytho
n27/include' '-I' 'c:/Python27/include' '-Wall'
'-Wdeclaration-after-statement'
'-Wpointer-arith' '-Wformat-nonliteral' '-Wno-pointer-sign' '-Wno-unused'
'-Wunu
sed-value' '-Wunused-function' '-Wno-switch' '-Wno-char-subscripts'
'-Wno-format
' '-Werror' '-c' '-o' 'main.o' '-MT' 'main.o' '-MMD' '-MP' '-MF'
'.deps/main.Tpo
' '-D' 'TARGET_SYSTEM_ROOT=""' '-D' 'TARGET_SYSTEM_ROOT_RELOCATABLE=0' '-D'
'BIN
DIR="E:/msys/mingw32/msys/1.0/local/bin"' '-mtune=i386' '-march=i386'
 e:/msys/mingw32/bin/../libexec/gcc/mingw32/4.6.1/cc1.exe -E -quiet -v -I .
-I .
./../puresrc/gdb -I ../../puresrc/gdb/common -I ../../puresrc/gdb/config -I
../.
./puresrc/gdb/../include/opcode -I ../../puresrc/gdb/../opcodes/.. -I
../../pure
src/gdb/../readline/.. -I ../bfd -I ../../puresrc/gdb/../bfd -I
../../puresrc/gd
b/../include -I ../libdecnumber -I ../../puresrc/gdb/../libdecnumber -I
../../pu
resrc/gdb/gnulib -I gnulib -I c:/Python27/include -I c:/Python27/include
-iprefi
x e:\msys\mingw32\bin\../lib/gcc/mingw32/4.6.1/ -MMD main.d -MF
.deps/main.Tpo -
MP -MT main.o -D LOCALEDIR="E:/msys/mingw32/msys/1.0/local/share/locale" -D
HAVE
_CONFIG_H -D TARGET_SYSTEM_ROOT="" -D TARGET_SYSTEM_ROOT_RELOCATABLE=0 -D
BINDIR
="E:/msys/mingw32/msys/1.0/local/bin" ../../puresrc/gdb/main.c -mtune=i386
-marc
h=i386 -Wall -Wdeclaration-after-statement -Wpointer-arith
-Wformat-nonliteral -
Wno-pointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch
-Wno-c
har-subscripts -Wno-format -Werror -g -fworking-directory -O0
-fpch-preprocess -
o main.i

Did you see want happens?
  -DBINDIR="/usr/local/bin\"
gets transformed into '-D' 'BINDIR="E:/msys/mingw32/msys/1.0/local/bin"'
inside COLLECT_GCC_OPTIONS!

So that once this compiled gdb executable is put to e:\pas\fpc-2.7.1\gdb\bin
relocate_gdb_directory function doesn't find any
common part between E:/msys/mingw32/msys/1.0/local/bin
and /usr/local/share/gdb
which leads to failure in directory relocation.

  I think that moving BINDIR also into config.h
should fix that msys specific failure.

Pierre Muller

Re: Building GDB 7.3.92 with MinGW

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> I normally keep the unstripped binary with the sources, but install
Eli> stripped ones.

As a workaround you can

    make install INSTALL_PROGRAM='install -s'

Tom

Re: Building GDB 7.3.92 with MinGW

[asmwarrior]

On 2012-1-11 5:31, Tom Tromey wrote:
>>>>>> "Eli" == Eli Zaretskii<eliz@gnu.org>  writes:
>
> Eli>  I normally keep the unstripped binary with the sources, but install
> Eli>  stripped ones.
>
> As a workaround you can
>
>      make install INSTALL_PROGRAM='install -s'
>
> Tom
>
Yeah, this is a better way, I found install-strip does not work under mingw for a long time.
Here is what I did before:
make install
cd to installed_folder
strp *.exe

I keep the unstripped binary in the build tree, because I can debug it under MinGW, I'm not sure I can do this if I move the stripped version to some other place, maybe I need to adjust the source path.

asmwarrior
ollydbg from codeblocks' forum

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Wed, 11 Jan 2012 08:42:12 +0800
> From: asmwarrior <asmwarrior@gmail.com>
> 
> Here is what I did before:
> make install
> cd to installed_folder
> strp *.exe

That doesn't strip the libraries, and if GDB will some time distribute
a shared library, won't DTRT with them.

Stripping libraries needs special switches to `strip' which is a pain
to type, and for *.a libraries you need to run ranlib afterwards.
"install-strip" does all that automatically.

Re: Building GDB 7.3.92 with MinGW

[asmwarrior]

On 2012-1-11 12:08, Eli Zaretskii wrote:
>> Date: Wed, 11 Jan 2012 08:42:12 +0800
>> >  From: asmwarrior<asmwarrior@gmail.com>
>> >  
>> >  Here is what I did before:
>> >  make install
>> >  cd to installed_folder
>> >  strp *.exe
> That doesn't strip the libraries, and if GDB will some time distribute
> a shared library, won't DTRT with them.
>
> Stripping libraries needs special switches to `strip' which is a pain
> to type, and for *.a libraries you need to run ranlib afterwards.
> "install-strip" does all that automatically.
Thank you very much!

Mostly I think I don't need the "include" and "lib" folder in gdb.
Do I need to develop a program depend on gdb's library? No
I only need "bin" and "shared" folder.

asmwarrior
ollydbg from codeblocks' forum

Re: Building GDB 7.3.92 with MinGW

[Joel Brobecker]

> 2. "make install-strip" fails in readline/, in sim/, and in gdb/:
[...]
> Finally, a question: Why are we installing libraries (libbfd,
> libopcodes, libiberty) and the standards.info manual?  The libraries
> are not part of GDB, we import them from elsewhere.  "make install"
> will happily overwrite existing installation of these libraries that
> could potentially be newer, coming from their respective upstream
> distributions.  How about removing these from "make install"?

We could side-step these issues by documenting in the README that
GDB should be installed using "make -C gdb install", or "make -C
gdb install-strip". This is what I personally do.

-- 
Joel

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Wed, 11 Jan 2012 07:24:41 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > 2. "make install-strip" fails in readline/, in sim/, and in gdb/:
> [...]
> > Finally, a question: Why are we installing libraries (libbfd,
> > libopcodes, libiberty) and the standards.info manual?  The libraries
> > are not part of GDB, we import them from elsewhere.  "make install"
> > will happily overwrite existing installation of these libraries that
> > could potentially be newer, coming from their respective upstream
> > distributions.  How about removing these from "make install"?
> 
> We could side-step these issues by documenting in the README that
> GDB should be installed using "make -C gdb install", or "make -C
> gdb install-strip". This is what I personally do.

I like this alternative the best.  Is the patch below OK to install,
including on the branch?

Index: gdb/README
===================================================================
RCS file: /cvs/src/src/gdb/README,v
retrieving revision 1.49
diff -u -r1.49 README
--- gdb/README	4 Jan 2012 04:11:38 -0000	1.49
+++ gdb/README	13 Jan 2012 10:52:12 -0000
@@ -39,6 +39,11 @@
       cd gdb-VERSION
       ./configure
       make
+      cd gdb
+      make install (or "make install-strip")
+
+Alternatively, install with
+
       cp gdb/gdb /usr/local/bin/gdb	(or wherever you want)
 
 However, we recommend that an empty directory be used instead.
@@ -52,7 +57,8 @@
       cd build
       <full path to your sources>/gdb-VERSION/configure
       make
-      cp gdb/gdb /usr/local/bin/gdb	(or wherever you want)
+      cd gdb
+      make install (or "make install-strip")
 
 (Building GDB with DJGPP tools for MS-DOS/MS-Windows is slightly
 different; see the file gdb-VERSION/gdb/config/djgpp/README for details.)
@@ -236,6 +242,15 @@
 configuration files for every directory level underneath (unless
 you tell it not to, with the `--norecursion' option).
 
+   After the build finishes successfully, you can install the built
+GDB like this:
+
+   cd gdb
+   make install
+
+   If you want to install a GDB binary stripped of debugging symbols,
+type "make install-strip" instead of the second line.
+
    You can install `gdb' anywhere; it has no hardwired paths. However,
 you should make sure that the shell on your path (named by the `SHELL'
 environment variable) is publicly readable.  Remember that GDB uses the

Re: Building GDB 7.3.92 with MinGW

[Joel Brobecker]

> I like this alternative the best.  Is the patch below OK to install,
> including on the branch?

It's OK with me for both HEAD and branch, with one possible suggestion:

> 
> Index: gdb/README
> ===================================================================
> RCS file: /cvs/src/src/gdb/README,v
> retrieving revision 1.49
> diff -u -r1.49 README
> --- gdb/README	4 Jan 2012 04:11:38 -0000	1.49
> +++ gdb/README	13 Jan 2012 10:52:12 -0000
> @@ -39,6 +39,11 @@
>        cd gdb-VERSION
>        ./configure
>        make
> +      cd gdb
> +      make install (or "make install-strip")
> +
> +Alternatively, install with
> +
>        cp gdb/gdb /usr/local/bin/gdb	(or wherever you want)

Do we really want to preserve the alternate solution? We have more
and more support files that come with GDB, so it's less and less
likely to install a fully-functional GDB. (it is fine with me if
we want to preserve it, just wanted to mention it).

-- 
Joel

Re: Building GDB 7.3.92 with MinGW

[Eli Zaretskii]

> Date: Fri, 13 Jan 2012 16:14:49 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > diff -u -r1.49 README
> > --- gdb/README	4 Jan 2012 04:11:38 -0000	1.49
> > +++ gdb/README	13 Jan 2012 10:52:12 -0000
> > @@ -39,6 +39,11 @@
> >        cd gdb-VERSION
> >        ./configure
> >        make
> > +      cd gdb
> > +      make install (or "make install-strip")
> > +
> > +Alternatively, install with
> > +
> >        cp gdb/gdb /usr/local/bin/gdb	(or wherever you want)
> 
> Do we really want to preserve the alternate solution? We have more
> and more support files that come with GDB, so it's less and less
> likely to install a fully-functional GDB. (it is fine with me if
> we want to preserve it, just wanted to mention it).

I agree; I was surprised to see that in README to begin with.  If no
one objects, I will remove that alternative.