Discussion:
[PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue
SiZiOUS
2018-08-28 12:01:35 UTC
Permalink
This little patch was made to allow the compilation under the MinGW/MSYS legacy environment (I don't know for the newer MinGW-w64/MSYS2 environment!).
If this patch is not applied, then the compilation of gdb-7.12.1 under MinGW/MSYS is impossible.

This fix is not intrusive as it's taken into account only if ERROR_IO_PENDING is not declared in the current scope, so it should be considered safe.
See the Bugzilla bug entry for more details.

Please note, this fix only allows the build possible under MinGW/MSYS, there is no bug fixes or improvements for GDB itself.

gdb/ChangeLog:
2018-08-28 SiZiOUS<***@gmail.com>

PR build/23568
* ser-mingw.c: Conditioned fix allowing compilation under
the MinGW/MSYS legacy environment ('ERROR_IO_PENDING' was not
declared in the scope).
Pedro Alves
2018-08-28 16:57:43 UTC
Permalink
Hi,
Post by SiZiOUS
This little patch was made to allow the compilation under the MinGW/MSYS legacy environment (I don't know for the newer MinGW-w64/MSYS2 environment!).
If this patch is not applied, then the compilation of gdb-7.12.1 under MinGW/MSYS is impossible.
GDB 7.12 is old by now and not actively maintained.

Can you check whether this is necessary on the master branch?

Also, it's a bit curious that nobody else ran into this so far. Could it
be you're using an older mingw and that the issue has been fixed in the
mingw/w32api headers meanwhile?
Post by SiZiOUS
This fix is not intrusive as it's taken into account only if ERROR_IO_PENDING is not declared in the current scope, so it should be considered safe.
See the Bugzilla bug entry for more details.
Please note, this fix only allows the build possible under MinGW/MSYS, there is no bug fixes or improvements for GDB itself.
    PR build/23568
    * ser-mingw.c: Conditioned fix allowing compilation under
    the MinGW/MSYS legacy environment ('ERROR_IO_PENDING' was not
    declared in the scope).
Thanks,
Pedro Alves
Eli Zaretskii
2018-08-28 17:22:43 UTC
Permalink
Date: Tue, 28 Aug 2018 17:57:43 +0100
Post by SiZiOUS
This little patch was made to allow the compilation under the MinGW/MSYS legacy environment (I don't know for the newer MinGW-w64/MSYS2 environment!).
If this patch is not applied, then the compilation of gdb-7.12.1 under MinGW/MSYS is impossible.
GDB 7.12 is old by now and not actively maintained.
Can you check whether this is necessary on the master branch?
AFAICS, we include winerror.h via serial.h, which includes winsock2.h,
which includes winerror.h. Older MinGW included that via the chain
windows.h->windef.h->winnt.h.

SiZiOUS, what version of the MinGW runtime are you using?
SiZiOUS
2018-08-28 22:19:36 UTC
Permalink
Hello,

Thank you very much for your interest to my patch.

I'm using the MinGW/MSYS installer from the official SourceForge page:
https://sourceforge.net/projects/mingw/

Please note, I'm using the original MinGW/MSYS environment, not the
newer MinGW-w64/MSYS2 environment which is a completely new project,
with no links from the original one.
The problem for me with MinGW-w64/MSYS2 is they dropped Windows XP
support (and I understand that) but for my purpose I need XP support, as
I targetting an old exotic platform (Sega Dreamcast if you're
wondering), so I'm targetting GDB with sh-elf (fyi it's a Hitachi SH-4 CPU).

I did a new try on a completely fresh MinGW/MSYS installation just to be
sure:

1- Download "mingw-get-setup.exe" from
https://sourceforge.net/projects/mingw/ - it shows
v0.6.2-beta-20131004-1 (It's just the MinGW Installation Manager Setup
Tool version).
2- Click Install.
3- Install packages : mingw32-base, mingw32-gcc-g++, msys-base. GCC is
6.3.0-1.
4- Open MSYS Shell.
5- Unpack gdb-7.12.1 in the home directory or somewhere else.
6- Then execute the following command to launch the GDB build:
"configure --disable-werror --prefix=/opt/toolchains/dc/sh-elf
--target=sh-elf", followed by "make".

If you not apply my patch, then you'll get the following error near the
build end:

ser-mingw.c: In function 'int ser_windows_read_prim(serial*, size_t)':
ser-mingw.c:346:30: error: 'ERROR_IO_PENDING' was not declared in this scope
       if (GetLastError () != ERROR_IO_PENDING
                              ^~~~~~~~~~~~~~~~
ser-mingw.c: In function 'int ser_windows_write_prim(serial*, const
void*, size_t)':
ser-mingw.c:368:30: error: 'ERROR_IO_PENDING' was not declared in this scope
       if (GetLastError () != ERROR_IO_PENDING
                              ^~~~~~~~~~~~~~~~
make[2]: *** [ser-mingw.o] Error 1

I tried the latest 8.0 build but it doesn't compile too.
Anyway I'm sticking to the 7.x branch as the GDB 7.x is confirmed to
work with the Sega Dreamcast platform.

And I know, the MinGW/MSYS original project is maintained but almost
deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
support for my needs.
I proposed this patch because it's really simple and not intrusive, but
you're right, how many people uses that old MinGW/MSYS project?

Thank you for reading me in all the cases!

BR,
SiZiOUS
Post by Eli Zaretskii
Date: Tue, 28 Aug 2018 17:57:43 +0100
Post by SiZiOUS
This little patch was made to allow the compilation under the MinGW/MSYS legacy environment (I don't know for the newer MinGW-w64/MSYS2 environment!).
If this patch is not applied, then the compilation of gdb-7.12.1 under MinGW/MSYS is impossible.
GDB 7.12 is old by now and not actively maintained.
Can you check whether this is necessary on the master branch?
AFAICS, we include winerror.h via serial.h, which includes winsock2.h,
which includes winerror.h. Older MinGW included that via the chain
windows.h->windef.h->winnt.h.
SiZiOUS, what version of the MinGW runtime are you using?
SiZiOUS
2018-08-29 08:04:20 UTC
Permalink
Hi there,

Just for your information, I tried to build gdb-8.1.1 under MinGW/MSYS
and it doesn't work, due to a similar reason.
I opened a bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23583

Have a nice day.
M. Laranjeira
Post by SiZiOUS
Hello,
Thank you very much for your interest to my patch.
https://sourceforge.net/projects/mingw/
Please note, I'm using the original MinGW/MSYS environment, not the
newer MinGW-w64/MSYS2 environment which is a completely new project,
with no links from the original one.
The problem for me with MinGW-w64/MSYS2 is they dropped Windows XP
support (and I understand that) but for my purpose I need XP support,
as I targetting an old exotic platform (Sega Dreamcast if you're
wondering), so I'm targetting GDB with sh-elf (fyi it's a Hitachi SH-4 CPU).
I did a new try on a completely fresh MinGW/MSYS installation just to
1- Download "mingw-get-setup.exe" from
https://sourceforge.net/projects/mingw/ - it shows
v0.6.2-beta-20131004-1 (It's just the MinGW Installation Manager Setup
Tool version).
2- Click Install.
3- Install packages : mingw32-base, mingw32-gcc-g++, msys-base. GCC is
6.3.0-1.
4- Open MSYS Shell.
5- Unpack gdb-7.12.1 in the home directory or somewhere else.
"configure --disable-werror --prefix=/opt/toolchains/dc/sh-elf
--target=sh-elf", followed by "make".
If you not apply my patch, then you'll get the following error near
ser-mingw.c:346:30: error: 'ERROR_IO_PENDING' was not declared in this scope
       if (GetLastError () != ERROR_IO_PENDING
                              ^~~~~~~~~~~~~~~~
ser-mingw.c: In function 'int ser_windows_write_prim(serial*, const
ser-mingw.c:368:30: error: 'ERROR_IO_PENDING' was not declared in this scope
       if (GetLastError () != ERROR_IO_PENDING
                              ^~~~~~~~~~~~~~~~
make[2]: *** [ser-mingw.o] Error 1
I tried the latest 8.0 build but it doesn't compile too.
Anyway I'm sticking to the 7.x branch as the GDB 7.x is confirmed to
work with the Sega Dreamcast platform.
And I know, the MinGW/MSYS original project is maintained but almost
deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
support for my needs.
I proposed this patch because it's really simple and not intrusive,
but you're right, how many people uses that old MinGW/MSYS project?
Thank you for reading me in all the cases!
BR,
SiZiOUS
Post by Eli Zaretskii
Date: Tue, 28 Aug 2018 17:57:43 +0100
Post by SiZiOUS
This little patch was made to allow the compilation under the
MinGW/MSYS legacy environment (I don't know for the newer
MinGW-w64/MSYS2 environment!).
If this patch is not applied, then the compilation of gdb-7.12.1
under MinGW/MSYS is impossible.
GDB 7.12 is old by now and not actively maintained.
Can you check whether this is necessary on the master branch?
AFAICS, we include winerror.h via serial.h, which includes winsock2.h,
which includes winerror.h.  Older MinGW included that via the chain
windows.h->windef.h->winnt.h.
SiZiOUS, what version of the MinGW runtime are you using?
Eli Zaretskii
2018-09-09 20:06:26 UTC
Permalink
Date: Wed, 29 Aug 2018 10:04:20 +0200
Just for your information, I tried to build gdb-8.1.1 under MinGW/MSYS
and it doesn't work, due to a similar reason.
I opened a bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23583
FWIW, building GDB 8.2 with the latest version 5.1.1 of the MinGW
runtime and w32 API headers doesn't have this problem, it builds
cleanly (modulo a few harmless warnings). So I suggest to upgrade to
the latest MinGW headers.
SiZiOUS
2018-12-02 13:52:04 UTC
Permalink
Hello,

Long time no see, sorry for this delay.
Thanks for the information, about the 5.1.1 of the MinGW runtime and
Win32 API headers.

This is really strange, I don't get it. The official mingw-get-setup
tool from the official repo (https://fr.osdn.net/projects/mingw/) are
using manifest files in date of 20170905, i.e. the MinGW runtime I use
is 5.0.2.
So why making an update tool that doesn't do any updates sounds strange
to me. So definitely my issue is related to the MinGW project update
policy I guess.

By the way I finally moved from 7.12.1 to GDB 8.2 as I had a severe bug
with remote debugging through a gdb stub (something related to a 'tp'
thread assertion error).
So I tried to compile GDB 8.2 with that (outdated?! but out-of-the-box!)
MinGW environment and still have errors related to winsock2.
So I made a diff patch to add some non-destructive instructions that
you'll find attached. Feel free to use it or not.

If you wouldn't mind, I have a little question about remote debugging.
What's the proper way to tell the gdb client the fact that the remote
process has ended?
If I understand well, I just need to close the connection (i.e. closing
the socket). But sometimes it's working (i.e. gdb client shows "Remote
connection ended") and sometimes it won't (gdb shows "Remote
communication error: Not a directory" or "Remote communication error: No
such file or directory").

I have the following:
target process ("hello.elf") <-----> application uploader/runner
("dc-tool.exe") <-----> gdb client ("sh-elf-gdb")
target arch (sh-elf)                   |         host arch (pc win32)

dc-tool is a custom program which is reponsible to upload and execute
the program on the target. gdb client passes through it to interact with
the target program.
That means, the gdb server handling is in the dc-tool program.

I think part of the answer is the notification packet:
https://sourceware.org/gdb/onlinedocs/gdb/Notification-Packets.html#Notification-Packets

But I don't know if it's true and I don't know how to implement this.

Thank you for your time.

BR,
Mike
Post by Eli Zaretskii
Date: Wed, 29 Aug 2018 10:04:20 +0200
Just for your information, I tried to build gdb-8.1.1 under MinGW/MSYS
and it doesn't work, due to a similar reason.
I opened a bug:https://sourceware.org/bugzilla/show_bug.cgi?id=23583
FWIW, building GDB 8.2 with the latest version 5.1.1 of the MinGW
runtime and w32 API headers doesn't have this problem, it builds
cleanly (modulo a few harmless warnings).  So I suggest to upgrade to
the latest MinGW headers.
Simon Marchi
2018-08-29 15:50:43 UTC
Permalink
Post by SiZiOUS
Please note, I'm using the original MinGW/MSYS environment, not the
newer MinGW-w64/MSYS2 environment which is a completely new project,
with no links from the original one.
The problem for me with MinGW-w64/MSYS2 is they dropped Windows XP
support (and I understand that) but for my purpose I need XP support,
as I targetting an old exotic platform (Sega Dreamcast if you're
wondering), so I'm targetting GDB with sh-elf (fyi it's a Hitachi SH-4 CPU).
That sounds awesome :). You are working with real hardware? You need
Windows XP because that's what the original tools for that platform
support?
Post by SiZiOUS
ser-mingw.c:346:30: error: 'ERROR_IO_PENDING' was not declared in this scope
       if (GetLastError () != ERROR_IO_PENDING
                              ^~~~~~~~~~~~~~~~
ser-mingw.c: In function 'int ser_windows_write_prim(serial*, const
ser-mingw.c:368:30: error: 'ERROR_IO_PENDING' was not declared in this scope
       if (GetLastError () != ERROR_IO_PENDING
                              ^~~~~~~~~~~~~~~~
make[2]: *** [ser-mingw.o] Error 1
If this constant is supposed to be defined in the win32 API but is
missing with mingw, could it be that it's more of a mingw bug, and it
should be fixed there?
Post by SiZiOUS
I tried the latest 8.0 build but it doesn't compile too.
Anyway I'm sticking to the 7.x branch as the GDB 7.x is confirmed to
work with the Sega Dreamcast platform.
Just wondering, which 7.x version is confirmed to work with that
platform? Functionality-wise, there's no more difference between the
7.12 and 8.0 releases, for example, than there are between 7.11 and
7.12. The numbers are pretty much arbitrary. So let's say GDB 7.6 was
known to work, there's no reason to use 7.12 over what is the latest
released GDB at the moment (unless you actually have a problem with the
latest release, in which case we want to know!).
Post by SiZiOUS
And I know, the MinGW/MSYS original project is maintained but almost
deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
support for my needs.
I proposed this patch because it's really simple and not intrusive,
but you're right, how many people uses that old MinGW/MSYS project?
If the missing definition is indeed a mingw bug, but there is really no
way of getting a new mingw release with that fixed because the project
is unmaintained (but still useful to some people), I would not be
against a patch like what you proposed. I would however add a clear
comment for why this is needed, so that if some day we officially decide
not to support this mingw, we can remove it.

Simon
Eli Zaretskii
2018-08-29 16:18:51 UTC
Permalink
Date: Wed, 29 Aug 2018 11:50:43 -0400
Post by SiZiOUS
ser-mingw.c:368:30: error: 'ERROR_IO_PENDING' was not declared in this scope
       if (GetLastError () != ERROR_IO_PENDING
                              ^~~~~~~~~~~~~~~~
make[2]: *** [ser-mingw.o] Error 1
If this constant is supposed to be defined in the win32 API but is
missing with mingw, could it be that it's more of a mingw bug, and it
should be fixed there?
It is not a MinGW bug: this constant is defined in winerror.h that
comes with MinGW's w32api package.

The problem seems to be that winerror.h somehow doesn't get included
in that source file, neither directly nor indirectly. I will try to
look into it some time soon.
Tom Tromey
2018-08-29 16:24:35 UTC
Permalink
Post by SiZiOUS
And I know, the MinGW/MSYS original project is maintained but almost
deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
support for my needs.
I proposed this patch because it's really simple and not intrusive,
but you're right, how many people uses that old MinGW/MSYS project?
Simon> If the missing definition is indeed a mingw bug, but there is really
Simon> no way of getting a new mingw release with that fixed because the
Simon> project is unmaintained (but still useful to some people), I would not
Simon> be against a patch like what you proposed. I would however add a
Simon> clear comment for why this is needed, so that if some day we
Simon> officially decide not to support this mingw, we can remove it.

Also, is there any downside to the original patch?
If not then I think we might as well accept it, subject to Simon's
request here.

Tom
SiZiOUS
2018-08-29 17:00:41 UTC
Permalink
Post by Tom Tromey
Post by SiZiOUS
And I know, the MinGW/MSYS original project is maintained but almost
deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
support for my needs.
I proposed this patch because it's really simple and not intrusive,
but you're right, how many people uses that old MinGW/MSYS project?
Simon> If the missing definition is indeed a mingw bug, but there is really
Simon> no way of getting a new mingw release with that fixed because the
Simon> project is unmaintained (but still useful to some people), I would not
Simon> be against a patch like what you proposed. I would however add a
Simon> clear comment for why this is needed, so that if some day we
Simon> officially decide not to support this mingw, we can remove it.
Also, is there any downside to the original patch?
If not then I think we might as well accept it, subject to Simon's
request here.
Nope, as it only includes the winerror.h header file just in case that
the ERROR_IO_PENDING is undefined.
So if ERROR_IO_PENDING is defined (as it would be normally), my patch
does nothing.
Post by Tom Tromey
Tom
Pedro Alves
2018-08-29 17:45:47 UTC
Permalink
Post by Tom Tromey
Post by SiZiOUS
And I know, the MinGW/MSYS original project is maintained but almost
deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
support for my needs.
I proposed this patch because it's really simple and not intrusive,
but you're right, how many people uses that old MinGW/MSYS project?
Simon> If the missing definition is indeed a mingw bug, but there is really
Simon> no way of getting a new mingw release with that fixed because the
Simon> project is unmaintained (but still useful to some people), I would not
Simon> be against a patch like what you proposed. I would however add a
Simon> clear comment for why this is needed, so that if some day we
Simon> officially decide not to support this mingw, we can remove it.
Also, is there any downside to the original patch?
If not then I think we might as well accept it, subject to Simon's
request here.
AFAICT, we don't know for sure whether it's necessary on the master
branch. The issue reported at <https://sourceware.org/bugzilla/show_bug.cgi?id=23583>
seems similar, but the patch will not fix it, making it pointless on its own.

It's possible that identifying a fix for the gnulib side may reveal
a different fix for the gdb side accordingly.

SiZiOUS can you try building the git master branch, or a recent
snapshot? See:

https://sourceware.org/gdb/current/

For example:
ftp://sourceware.org/pub/gdb/snapshots/current/gdb-8.2.50.20180829.tar.xz

The best would be current git master (or wait for a snapshot tomorrow),
because we just updated the gnulib copy in our tree.

Also, why do we need the #ifndef? Would unconditionally
include winerr.h cause problems?

Thanks,
Pedro Alves
SiZiOUS
2018-08-29 16:59:29 UTC
Permalink
Hi Simon!
Post by SiZiOUS
Please note, I'm using the original MinGW/MSYS environment, not the
newer MinGW-w64/MSYS2 environment which is a completely new project,
with no links from the original one.
The problem for me with MinGW-w64/MSYS2 is they dropped Windows XP
support (and I understand that) but for my purpose I need XP support,
as I targetting an old exotic platform (Sega Dreamcast if you're
wondering), so I'm targetting GDB with sh-elf (fyi it's a Hitachi SH-4 CPU).
That sounds awesome :).  You are working with real hardware?
Yes, I'm working on the real hardware as I'm a Sega Dreamcast enthusiasm
for at least 20 years. And we all love old stuffs, right? ;)
You need Windows XP because that's what the original tools for that
platform support?
You pointed at it. The Sega Dreamcast was released back in '98, so the
golden era of Windows 98 and NT/2K/XP. XP is old today but it's still
usable (unlike 98/NT/2K...).
So I own a modern setup for my daily usage (Windows 10) and an old
workstation with XP dedicated for my Sega Dreamcast development sessions.

But I don't use the official Sega SDK for legal reasons and mainly
because the tools are really old. But as my Dreamcast hardware is
connected to my XP computer throught an old COM port, and there is some
old tools that works only on XP, I'm stick with that environment for
that usage. That's why I'm still using the old MinGW/MSYS project
instead of the newer (and really good) MinGW-w64/MSYS2.
Post by SiZiOUS
ser-mingw.c:346:30: error: 'ERROR_IO_PENDING' was not declared in this scope
       if (GetLastError () != ERROR_IO_PENDING
                              ^~~~~~~~~~~~~~~~
ser-mingw.c: In function 'int ser_windows_write_prim(serial*, const
ser-mingw.c:368:30: error: 'ERROR_IO_PENDING' was not declared in this scope
       if (GetLastError () != ERROR_IO_PENDING
                              ^~~~~~~~~~~~~~~~
make[2]: *** [ser-mingw.o] Error 1
If this constant is supposed to be defined in the win32 API but is
missing with mingw, could it be that it's more of a mingw bug, and it
should be fixed there?
It's defined in winerror.h in the W32API package but for an unknown
reason it isn't taken into account when compiling GDB.
So that's the fix: if the constant is undefined for some reason, I force
the inclusion of it. That's why I'm calling this little fix "not
intrusive". Not doing so will prevent the compilation of GDB anyway.
Post by SiZiOUS
I tried the latest 8.0 build but it doesn't compile too.
Anyway I'm sticking to the 7.x branch as the GDB 7.x is confirmed to
work with the Sega Dreamcast platform.
Just wondering, which 7.x version is confirmed to work with that
platform?  Functionality-wise, there's no more difference between the
7.12 and 8.0 releases, for example, than there are between 7.11 and
7.12.  The numbers are pretty much arbitrary.  So let's say GDB 7.6
was known to work, there's no reason to use 7.12 over what is the
latest released GDB at the moment (unless you actually have a problem
with the latest release, in which case we want to know!).
My thought was simpler.

In fact, I use the KallistiOS library which is an open source library
that gives access to hardware resources of the Dreamcast from homebrew
programs.
In that library, there is a complete Makefile (which doesn't work
out-of-the-box for MinGW/MSYS, so that's the purpose of my work) setting
up the complete toolchain for making Dreamcast apps.
In that Makefile (which is called "dc-chain" FYI), a lot of stuffs are
made for setting up the development environment. We had some problems
with newer versions of GCC, i.e. we used GCC 4.8.2 some time but it
produces instable code for the Dreamcast, so the GCC version was
reverted back to the 4.7.3 version. So I don't even think about updating
to modern GCC...

I know this is the mailing list for GDB so talking about GCC here is
unrevelant: the thing is, as you can see, the Dreamcast is old, exotic
and I'm not surprised if GCC is not working properly.
So I was thinking the same for GDB.

But in fact, GDB 7.11.1 is confirmed to work. As this version isn't
compiling under MinGW for some reason, I updated to the latest 7.x
version, and the only issue I had was this little build problem.
I've not tested GDB now, so I don't know if it's work or not with the
Dreamcast.

For the 8.x, I opened a bug about building on MinGW, but seems to be a
similar reason.
Post by SiZiOUS
And I know, the MinGW/MSYS original project is maintained but almost
deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
support for my needs.
I proposed this patch because it's really simple and not intrusive,
but you're right, how many people uses that old MinGW/MSYS project?
If the missing definition is indeed a mingw bug, but there is really
no way of getting a new mingw release with that fixed because the
project is unmaintained (but still useful to some people), I would not
be against a patch like what you proposed.  I would however add a
clear comment for why this is needed, so that if some day we
officially decide not to support this mingw, we can remove it.
Up to you :)
I'm just proposing this patch as it was really simple to do and could
help others (especially with basic "C/C++" skills, e.g. students...).
But I don't know if it's revelant for MinGW-w64/MSYS2 or not, but it's
the case for at least the MinGW/MSYS project!
Simon
Pedro Alves
2018-08-29 18:27:17 UTC
Permalink
But in fact, GDB 7.11.1 is confirmed to work. As this version isn't compiling under MinGW for some reason, I updated to the latest 7.x version, and the only issue I had was this little build problem.
I've not tested GDB now, so I don't know if it's work or not with the Dreamcast.
For the 8.x, I opened a bug about building on MinGW, but seems to be a similar reason.
I think you're confused with GDB's release numbering.
The set of 7.x releases are not all part of a single maintenance "gdb 7"
tree/family. Likewise, set of 8.x releases are not all part of a
single maintenance "gdb 8" tree/family. I.e., 7.12 is not a maintenance
release of 7.11. 7.11 is not a maintenance release of 7.10. etc.

GDB 7.12 was just as much of an increase over 7.11, as 8.0 was over 7.12.
It just happened that when we got all the way up to "12" we though that
that would be a good time to roll over to 8.0, because small numbers are
nice.

Maintenance bugfix releases are instead the z in x.y.z, as in
7.11.1, 7.11.2, etc.

Currently, we're about to release gdb 8.2, so the 8.2.x branch
in git is open for regression bugfixes. Build fixes like yours
would be a good fit too. It's possible to merge fixes to older
branches, but it's not very usual. As we move on to newer
releases, the older branches tend to become unmaintained.

Thanks,
Pedro Alves
SiZiOUS
2018-08-29 21:07:16 UTC
Permalink
First of all, thank for your time!
Also thanks for the explanation, you're right, I was thinking 7.12 was
maintenance release of 7.11 and I understand that isn't the case.

Just for your information, I tried as requested to compile the current
version of gdb (gdb-8.2.50.20180829), just to know the results.
It doesn't compile:

  CXX    ser-tcp.o
ser-tcp.c:43:21: fatal error: wspiapi.h: No such file or directory
 #include <wspiapi.h>
                     ^
compilation terminated.
make[2]: *** [ser-tcp.o] Error 1

I searched this file in my MinGW install but no luck, so I went to
Internet and found something:
https://groups.google.com/forum/#!topic/wx-dev/mquqPOh8fFs

That file doesn't exist on MinGW, but exists on MinGW-w64.

According to the post above, I tried to fix the issue with:

#ifdef __MINGW32__
#include <ws2spi.h>
#else
#include <wspiapi.h>
#endif

But new errors are coming:

  CXX    ser-tcp.o
ser-tcp.c: In function 'int try_connect(const addrinfo*, unsigned int*)':
ser-tcp.c:171:39: error: invalid use of incomplete type 'const struct
addrinfo'
   int sock = gdb_socket_cloexec (ainfo->ai_family, ainfo->ai_socktype,
                                       ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
   explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                         ^~~~~~~~
ser-tcp.c:171:57: error: invalid use of incomplete type 'const struct
addrinfo'
   int sock = gdb_socket_cloexec (ainfo->ai_family, ainfo->ai_socktype,
                                                         ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
   explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                         ^~~~~~~~
ser-tcp.c:172:11: error: invalid use of incomplete type 'const struct
addrinfo'
      ainfo->ai_protocol);
           ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
   explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                         ^~~~~~~~
ser-tcp.c:188:27: error: invalid use of incomplete type 'const struct
addrinfo'
   if (connect (sock, ainfo->ai_addr, ainfo->ai_addrlen) < 0)
                           ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
   explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                         ^~~~~~~~
ser-tcp.c:188:43: error: invalid use of incomplete type 'const struct
addrinfo'
   if (connect (sock, ainfo->ai_addr, ainfo->ai_addrlen) < 0)
                                           ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
   explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                         ^~~~~~~~
ser-tcp.c: In function 'int net_open(serial*, const char*)':
ser-tcp.c:283:19: error: aggregate 'addrinfo hint' has incomplete type
and cannot be defined
   struct addrinfo hint;
                   ^~~~
ser-tcp.c:300:23: error: 'getaddrinfo' was not declared in this scope
          &hint, &ainfo);
                       ^
ser-tcp.c:305:27: error: 'gai_strerror' was not declared in this scope
      name, gai_strerror (r));
                           ^
ser-tcp.c:327:68: error: invalid use of incomplete type 'struct addrinfo'
       for (struct addrinfo *iter = ainfo; iter != NULL; iter =
iter->ai_next)
^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
   explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                         ^~~~~~~~
ser-tcp.c:378:20: error: invalid use of incomplete type 'struct addrinfo'
   if (success_ainfo->ai_protocol == IPPROTO_TCP)
                    ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
   explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                         ^~~~~~~~
make[2]: *** [ser-tcp.o] Error 1

So this time, fixing GDB for MinGW is harder than 7.12.1.
Too tired to do that now.

Have a good night,
Mike Laranjeira (SiZiOUS)
Post by Pedro Alves
But in fact, GDB 7.11.1 is confirmed to work. As this version isn't compiling under MinGW for some reason, I updated to the latest 7.x version, and the only issue I had was this little build problem.
I've not tested GDB now, so I don't know if it's work or not with the Dreamcast.
For the 8.x, I opened a bug about building on MinGW, but seems to be a similar reason.
I think you're confused with GDB's release numbering.
The set of 7.x releases are not all part of a single maintenance "gdb 7"
tree/family. Likewise, set of 8.x releases are not all part of a
single maintenance "gdb 8" tree/family. I.e., 7.12 is not a maintenance
release of 7.11. 7.11 is not a maintenance release of 7.10. etc.
GDB 7.12 was just as much of an increase over 7.11, as 8.0 was over 7.12.
It just happened that when we got all the way up to "12" we though that
that would be a good time to roll over to 8.0, because small numbers are
nice.
Maintenance bugfix releases are instead the z in x.y.z, as in
7.11.1, 7.11.2, etc.
Currently, we're about to release gdb 8.2, so the 8.2.x branch
in git is open for regression bugfixes. Build fixes like yours
would be a good fit too. It's possible to merge fixes to older
branches, but it's not very usual. As we move on to newer
releases, the older branches tend to become unmaintained.
Thanks,
Pedro Alves
Pedro Alves
2018-08-29 17:54:23 UTC
Permalink
If the missing definition is indeed a mingw bug, but there is really no way of getting a new mingw release with that fixed because the project is unmaintained (but still useful to some people), I would not be against a patch like what you proposed.  I would however add a clear comment for why this is needed, so that if some day we officially decide not to support this mingw, we can remove it.
Not sure about mingw.org (the original mingw) being unmaintained.
There seems to have been recent commits:
https://sourceforge.net/p/mingw/mailman/mingw-cvs/

Thanks,
Pedro Alves
Eli Zaretskii
2018-08-29 18:09:30 UTC
Permalink
Date: Wed, 29 Aug 2018 18:54:23 +0100
Not sure about mingw.org (the original mingw) being unmaintained.
It's definitely maintained. Version 5.1 of the runtime was released 6
months ago and GCC 7.3.0 2 months ago.
https://sourceforge.net/p/mingw/mailman/mingw-cvs/
Actually, the source tree is here:

https://osdn.net/projects/mingw/scm/git/mingw-org-wsl
Loading...