* Building GDB 7.3.92 with MinGW @ 2012-01-10 18:46 Eli Zaretskii 2012-01-10 18:59 ` Doug Evans ` (3 more replies) 0 siblings, 4 replies; 41+ messages in thread From: Eli Zaretskii @ 2012-01-10 18:46 UTC (permalink / raw) To: gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 18:46 Building GDB 7.3.92 with MinGW Eli Zaretskii @ 2012-01-10 18:59 ` Doug Evans 2012-01-10 20:56 ` Eli Zaretskii 2012-01-13 11:28 ` Eli Zaretskii 2012-01-10 19:25 ` Tom Tromey ` (2 subsequent siblings) 3 siblings, 2 replies; 41+ messages in thread From: Doug Evans @ 2012-01-10 18:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 18:59 ` Doug Evans @ 2012-01-10 20:56 ` Eli Zaretskii 2012-01-13 11:28 ` Eli Zaretskii 1 sibling, 0 replies; 41+ messages in thread From: Eli Zaretskii @ 2012-01-10 20:56 UTC (permalink / raw) To: Doug Evans; +Cc: gdb-patches > 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 18:59 ` Doug Evans 2012-01-10 20:56 ` Eli Zaretskii @ 2012-01-13 11:28 ` Eli Zaretskii 1 sibling, 0 replies; 41+ messages in thread From: Eli Zaretskii @ 2012-01-13 11:28 UTC (permalink / raw) To: Doug Evans; +Cc: gdb-patches > 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 18:46 Building GDB 7.3.92 with MinGW Eli Zaretskii 2012-01-10 18:59 ` Doug Evans @ 2012-01-10 19:25 ` Tom Tromey 2012-01-10 20:55 ` Joseph S. Myers ` (2 more replies) 2012-01-10 19:31 ` Alfred M. Szmidt 2012-01-11 3:32 ` Joel Brobecker 3 siblings, 3 replies; 41+ messages in thread From: Tom Tromey @ 2012-01-10 19:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches >>>>> "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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 19:25 ` Tom Tromey @ 2012-01-10 20:55 ` Joseph S. Myers 2012-01-10 20:58 ` Eli Zaretskii 2012-01-10 21:00 ` Eli Zaretskii 2 siblings, 0 replies; 41+ messages in thread From: Joseph S. Myers @ 2012-01-10 20:55 UTC (permalink / raw) To: Tom Tromey; +Cc: Eli Zaretskii, gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 19:25 ` Tom Tromey 2012-01-10 20:55 ` Joseph S. Myers @ 2012-01-10 20:58 ` Eli Zaretskii 2012-01-10 21:00 ` Eli Zaretskii 2 siblings, 0 replies; 41+ messages in thread From: Eli Zaretskii @ 2012-01-10 20:58 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 19:25 ` Tom Tromey 2012-01-10 20:55 ` Joseph S. Myers 2012-01-10 20:58 ` Eli Zaretskii @ 2012-01-10 21:00 ` Eli Zaretskii 2 siblings, 0 replies; 41+ messages in thread From: Eli Zaretskii @ 2012-01-10 21:00 UTC (permalink / raw) To: Tom Tromey, DJ Delorie; +Cc: gdb-patches > 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? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 18:46 Building GDB 7.3.92 with MinGW Eli Zaretskii 2012-01-10 18:59 ` Doug Evans 2012-01-10 19:25 ` Tom Tromey @ 2012-01-10 19:31 ` Alfred M. Szmidt 2012-01-10 21:01 ` Eli Zaretskii 2012-01-11 3:32 ` Joel Brobecker 3 siblings, 1 reply; 41+ messages in thread From: Alfred M. Szmidt @ 2012-01-10 19:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 19:31 ` Alfred M. Szmidt @ 2012-01-10 21:01 ` Eli Zaretskii 2012-01-10 21:26 ` Doug Evans 2012-01-10 21:33 ` Tom Tromey 0 siblings, 2 replies; 41+ messages in thread From: Eli Zaretskii @ 2012-01-10 21:01 UTC (permalink / raw) To: ams; +Cc: gdb-patches > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 21:01 ` Eli Zaretskii @ 2012-01-10 21:26 ` Doug Evans 2012-01-11 0:37 ` asmwarrior 2012-01-10 21:33 ` Tom Tromey 1 sibling, 1 reply; 41+ messages in thread From: Doug Evans @ 2012-01-10 21:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ams, gdb-patches 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. :-) ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 21:26 ` Doug Evans @ 2012-01-11 0:37 ` asmwarrior 2012-01-11 4:08 ` Eli Zaretskii 2012-01-11 17:54 ` Doug Evans 0 siblings, 2 replies; 41+ messages in thread From: asmwarrior @ 2012-01-11 0:37 UTC (permalink / raw) To: gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-11 0:37 ` asmwarrior @ 2012-01-11 4:08 ` Eli Zaretskii 2012-01-11 4:54 ` asmwarrior 2012-01-11 17:54 ` Doug Evans 1 sibling, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2012-01-11 4:08 UTC (permalink / raw) To: asmwarrior; +Cc: gdb-patches > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-11 4:08 ` Eli Zaretskii @ 2012-01-11 4:54 ` asmwarrior 0 siblings, 0 replies; 41+ messages in thread From: asmwarrior @ 2012-01-11 4:54 UTC (permalink / raw) To: gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-11 0:37 ` asmwarrior 2012-01-11 4:08 ` Eli Zaretskii @ 2012-01-11 17:54 ` Doug Evans 2012-01-12 0:17 ` asmwarrior 1 sibling, 1 reply; 41+ messages in thread From: Doug Evans @ 2012-01-11 17:54 UTC (permalink / raw) To: asmwarrior; +Cc: gdb-patches 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-11 17:54 ` Doug Evans @ 2012-01-12 0:17 ` asmwarrior 2012-01-12 6:47 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: asmwarrior @ 2012-01-12 0:17 UTC (permalink / raw) To: Doug Evans; +Cc: gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-12 0:17 ` asmwarrior @ 2012-01-12 6:47 ` Eli Zaretskii 2012-01-12 8:07 ` Joel Brobecker 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2012-01-12 6:47 UTC (permalink / raw) To: asmwarrior; +Cc: dje, gdb-patches > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-12 6:47 ` Eli Zaretskii @ 2012-01-12 8:07 ` Joel Brobecker 2012-01-12 11:54 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Joel Brobecker @ 2012-01-12 8:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: asmwarrior, dje, gdb-patches > 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-12 8:07 ` Joel Brobecker @ 2012-01-12 11:54 ` Eli Zaretskii 2012-01-12 12:35 ` Joel Brobecker 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2012-01-12 11:54 UTC (permalink / raw) To: Joel Brobecker; +Cc: asmwarrior, dje, gdb-patches > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-12 11:54 ` Eli Zaretskii @ 2012-01-12 12:35 ` Joel Brobecker 2012-01-12 16:59 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Joel Brobecker @ 2012-01-12 12:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: asmwarrior, dje, gdb-patches > > 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-12 12:35 ` Joel Brobecker @ 2012-01-12 16:59 ` Eli Zaretskii 2012-01-13 14:29 ` asmwarrior 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2012-01-12 16:59 UTC (permalink / raw) To: Joel Brobecker; +Cc: asmwarrior, dje, gdb-patches > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-12 16:59 ` Eli Zaretskii @ 2012-01-13 14:29 ` asmwarrior 2012-01-13 16:55 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: asmwarrior @ 2012-01-13 14:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Joel Brobecker, dje, gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-13 14:29 ` asmwarrior @ 2012-01-13 16:55 ` Eli Zaretskii 2012-01-14 13:53 ` asmwarrior [not found] ` <4F117B33.8080906@gmail.com> 0 siblings, 2 replies; 41+ messages in thread From: Eli Zaretskii @ 2012-01-13 16:55 UTC (permalink / raw) To: asmwarrior; +Cc: brobecker, dje, gdb-patches > 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? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-13 16:55 ` Eli Zaretskii @ 2012-01-14 13:53 ` asmwarrior [not found] ` <4F117B33.8080906@gmail.com> 1 sibling, 0 replies; 41+ messages in thread From: asmwarrior @ 2012-01-14 13:53 UTC (permalink / raw) To: gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
[parent not found: <4F117B33.8080906@gmail.com>]
* Re: Building GDB 7.3.92 with MinGW [not found] ` <4F117B33.8080906@gmail.com> @ 2012-01-14 18:15 ` Eli Zaretskii 2012-01-15 3:33 ` Pierre Muller ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Eli Zaretskii @ 2012-01-14 18:15 UTC (permalink / raw) To: asmwarrior; +Cc: brobecker, dje, gdb-patches > 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? ^ permalink raw reply [flat|nested] 41+ messages in thread
* RE: Building GDB 7.3.92 with MinGW 2012-01-14 18:15 ` Eli Zaretskii @ 2012-01-15 3:33 ` Pierre Muller [not found] ` <18546.4176851839$1326580387@news.gmane.org> [not found] ` <000001ccd30c$5ce854e0$16b8fea0$%muller@ics-cnrs.unistra.fr> 2 siblings, 0 replies; 41+ messages in thread From: Pierre Muller @ 2012-01-15 3:33 UTC (permalink / raw) To: 'Eli Zaretskii', 'asmwarrior'; +Cc: brobecker, dje, gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
[parent not found: <18546.4176851839$1326580387@news.gmane.org>]
* Re: Building GDB 7.3.92 with MinGW [not found] ` <18546.4176851839$1326580387@news.gmane.org> @ 2012-01-15 3:54 ` asmwarrior 0 siblings, 0 replies; 41+ messages in thread From: asmwarrior @ 2012-01-15 3:54 UTC (permalink / raw) To: Pierre Muller; +Cc: 'Eli Zaretskii', brobecker, dje, gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
[parent not found: <000001ccd30c$5ce854e0$16b8fea0$%muller@ics-cnrs.unistra.fr>]
* Re: Building GDB 7.3.92 with MinGW [not found] ` <000001ccd30c$5ce854e0$16b8fea0$%muller@ics-cnrs.unistra.fr> @ 2012-01-15 13:35 ` Eli Zaretskii 2012-01-15 17:01 ` Joel Brobecker ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Eli Zaretskii @ 2012-01-15 13:35 UTC (permalink / raw) To: Pierre Muller; +Cc: asmwarrior, brobecker, dje, gdb-patches > 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? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-15 13:35 ` Eli Zaretskii @ 2012-01-15 17:01 ` Joel Brobecker 2012-01-15 18:55 ` Eli Zaretskii 2012-01-15 18:01 ` Pierre Muller [not found] ` <000301ccd3a7$3db8c460$b92a4d20$%muller@ics-cnrs.unistra.fr> 2 siblings, 1 reply; 41+ messages in thread From: Joel Brobecker @ 2012-01-15 17:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Pierre Muller, asmwarrior, dje, gdb-patches [-- 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-15 17:01 ` Joel Brobecker @ 2012-01-15 18:55 ` Eli Zaretskii 0 siblings, 0 replies; 41+ messages in thread From: Eli Zaretskii @ 2012-01-15 18:55 UTC (permalink / raw) To: Joel Brobecker; +Cc: pierre.muller, asmwarrior, dje, gdb-patches > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* RE: Building GDB 7.3.92 with MinGW 2012-01-15 13:35 ` Eli Zaretskii 2012-01-15 17:01 ` Joel Brobecker @ 2012-01-15 18:01 ` Pierre Muller [not found] ` <000301ccd3a7$3db8c460$b92a4d20$%muller@ics-cnrs.unistra.fr> 2 siblings, 0 replies; 41+ messages in thread From: Pierre Muller @ 2012-01-15 18:01 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: asmwarrior, brobecker, dje, gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
[parent not found: <000301ccd3a7$3db8c460$b92a4d20$%muller@ics-cnrs.unistra.fr>]
* Re: Building GDB 7.3.92 with MinGW [not found] ` <000301ccd3a7$3db8c460$b92a4d20$%muller@ics-cnrs.unistra.fr> @ 2012-01-15 18:55 ` Eli Zaretskii 2012-01-16 3:08 ` Pierre Muller 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2012-01-15 18:55 UTC (permalink / raw) To: Pierre Muller; +Cc: asmwarrior, brobecker, dje, gdb-patches > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* RE: Building GDB 7.3.92 with MinGW 2012-01-15 18:55 ` Eli Zaretskii @ 2012-01-16 3:08 ` Pierre Muller 0 siblings, 0 replies; 41+ messages in thread From: Pierre Muller @ 2012-01-16 3:08 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: asmwarrior, brobecker, dje, gdb-patches > -----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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 21:01 ` Eli Zaretskii 2012-01-10 21:26 ` Doug Evans @ 2012-01-10 21:33 ` Tom Tromey 2012-01-11 1:31 ` asmwarrior 1 sibling, 1 reply; 41+ messages in thread From: Tom Tromey @ 2012-01-10 21:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ams, gdb-patches >>>>> "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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 21:33 ` Tom Tromey @ 2012-01-11 1:31 ` asmwarrior 2012-01-11 4:30 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: asmwarrior @ 2012-01-11 1:31 UTC (permalink / raw) To: gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-11 1:31 ` asmwarrior @ 2012-01-11 4:30 ` Eli Zaretskii 2012-01-11 4:30 ` asmwarrior 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2012-01-11 4:30 UTC (permalink / raw) To: asmwarrior; +Cc: gdb-patches > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-11 4:30 ` Eli Zaretskii @ 2012-01-11 4:30 ` asmwarrior 0 siblings, 0 replies; 41+ messages in thread From: asmwarrior @ 2012-01-11 4:30 UTC (permalink / raw) To: gdb-patches 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-10 18:46 Building GDB 7.3.92 with MinGW Eli Zaretskii ` (2 preceding siblings ...) 2012-01-10 19:31 ` Alfred M. Szmidt @ 2012-01-11 3:32 ` Joel Brobecker 2012-01-13 11:06 ` Eli Zaretskii 3 siblings, 1 reply; 41+ messages in thread From: Joel Brobecker @ 2012-01-11 3:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches > 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-11 3:32 ` Joel Brobecker @ 2012-01-13 11:06 ` Eli Zaretskii 2012-01-13 12:39 ` Joel Brobecker 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2012-01-13 11:06 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches > 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-13 11:06 ` Eli Zaretskii @ 2012-01-13 12:39 ` Joel Brobecker 2012-01-13 13:56 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Joel Brobecker @ 2012-01-13 12:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches > 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Building GDB 7.3.92 with MinGW 2012-01-13 12:39 ` Joel Brobecker @ 2012-01-13 13:56 ` Eli Zaretskii 0 siblings, 0 replies; 41+ messages in thread From: Eli Zaretskii @ 2012-01-13 13:56 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2012-01-15 22:03 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-01-10 18:46 Building GDB 7.3.92 with MinGW Eli Zaretskii 2012-01-10 18:59 ` Doug Evans 2012-01-10 20:56 ` Eli Zaretskii 2012-01-13 11:28 ` Eli Zaretskii 2012-01-10 19:25 ` Tom Tromey 2012-01-10 20:55 ` Joseph S. Myers 2012-01-10 20:58 ` Eli Zaretskii 2012-01-10 21:00 ` Eli Zaretskii 2012-01-10 19:31 ` Alfred M. Szmidt 2012-01-10 21:01 ` Eli Zaretskii 2012-01-10 21:26 ` Doug Evans 2012-01-11 0:37 ` asmwarrior 2012-01-11 4:08 ` Eli Zaretskii 2012-01-11 4:54 ` asmwarrior 2012-01-11 17:54 ` Doug Evans 2012-01-12 0:17 ` asmwarrior 2012-01-12 6:47 ` Eli Zaretskii 2012-01-12 8:07 ` Joel Brobecker 2012-01-12 11:54 ` Eli Zaretskii 2012-01-12 12:35 ` Joel Brobecker 2012-01-12 16:59 ` Eli Zaretskii 2012-01-13 14:29 ` asmwarrior 2012-01-13 16:55 ` Eli Zaretskii 2012-01-14 13:53 ` asmwarrior [not found] ` <4F117B33.8080906@gmail.com> 2012-01-14 18:15 ` Eli Zaretskii 2012-01-15 3:33 ` Pierre Muller [not found] ` <18546.4176851839$1326580387@news.gmane.org> 2012-01-15 3:54 ` asmwarrior [not found] ` <000001ccd30c$5ce854e0$16b8fea0$%muller@ics-cnrs.unistra.fr> 2012-01-15 13:35 ` Eli Zaretskii 2012-01-15 17:01 ` Joel Brobecker 2012-01-15 18:55 ` Eli Zaretskii 2012-01-15 18:01 ` Pierre Muller [not found] ` <000301ccd3a7$3db8c460$b92a4d20$%muller@ics-cnrs.unistra.fr> 2012-01-15 18:55 ` Eli Zaretskii 2012-01-16 3:08 ` Pierre Muller 2012-01-10 21:33 ` Tom Tromey 2012-01-11 1:31 ` asmwarrior 2012-01-11 4:30 ` Eli Zaretskii 2012-01-11 4:30 ` asmwarrior 2012-01-11 3:32 ` Joel Brobecker 2012-01-13 11:06 ` Eli Zaretskii 2012-01-13 12:39 ` Joel Brobecker 2012-01-13 13:56 ` Eli Zaretskii
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).