Native GDB for i686-w64-mingw32 toolchain

[Matthias Weißer]

2015-11-17 17:19 GMT+01:00 Bryan Hundven <bryanhundven@gmail.com>:
> The build failure is happening with native-gdb, not cross-gdb, correct?

Right.

> So native=build, not target or host.

Wrong. It seems to me that "Native gdb" in crosstools-ng context
means a gdb that runs on the target system. See also the help
text in config/debug/gdb.in.native

"Build and install a native gdb for the target, to run on the target."

And actually this step creates a file named gdb.exe which makes
me even more confident that this is a gdb to run on the target ;-)

Where cross gdb means

"Build and install a cross-gdb for the target, to run on host."

> Since it is on the build system, the build system should provide
> libexpat development files.

So, as it is a gdb that should run on the target it needs an expat
library build for the target. And crosstools-ng builds and installs
such a variant. But gdb configure fails to find it.

I got a private message from Thomas Tamandl which lead me
to a solution:

diff --git a/scripts/build/debug/300-gdb.sh b/scripts/build/debug/300-gdb.sh
index c025458..e577e33
--- a/scripts/build/debug/300-gdb.sh
+++ b/scripts/build/debug/300-gdb.sh
@@ -198,6 +198,7 @@ do_debug_gdb_build() {
             --target=${CT_TARGET}                       \
             --prefix=/usr                               \
             --with-build-sysroot="${CT_SYSROOT_DIR}"    \
+            --with-libexpat-prefix="${CT_SYSROOT_DIR}/usr" \
             --without-uiout                             \
             --disable-tui                               \
             --disable-gdbtk                             \


If you think this is a working solution (for me it is) feel free to merge it.

The only problem left is then that striping the gdbserver executable fails
in internals.sh as its name contains .exe

> P.S. Please don't top post.

Outlook disease ;-) Sorry.

Regards
Matthias

--
For unsubscribe information see http://sourceware.org/lists.html#faq