From: Doug Evans <dje@google.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: Building GDB 7.3.92 with MinGW
Date: Tue, 10 Jan 2012 18:59:00 -0000 [thread overview]
Message-ID: <CADPb22TAaiWxS-MjWZtpWutX9857hofz+k9zFCG+UFyExeaMyQ@mail.gmail.com> (raw)
In-Reply-To: <83hb03e9sx.fsf@gnu.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__)".
>
> 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.
next prev parent reply other threads:[~2012-01-10 18:46 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-10 18:46 Eli Zaretskii
2012-01-10 18:59 ` Doug Evans [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADPb22TAaiWxS-MjWZtpWutX9857hofz+k9zFCG+UFyExeaMyQ@mail.gmail.com \
--to=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).