Re: Building GDB 7.3.92 with MinGW

Doug Evans
2012-01-10T18:46:46Z

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.