Re: Building GDB 7.3.92 with MinGW

Tom Tromey
2012-01-10T19:12:36Z

>>>>> "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