[PR,build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

  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<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).
  

Hi,

On 08/28/2018 01:01 PM, SiZiOUS wrote:
> 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?

> 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<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).

Thanks,
Pedro Alves
  

> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 28 Aug 2018 17:57:43 +0100
> 
> On 08/28/2018 01:01 PM, SiZiOUS wrote:
> > 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?
  

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

Le 28/08/2018 à 19:22, Eli Zaretskii a écrit :
>> From: Pedro Alves <palves@redhat.com>
>> Date: Tue, 28 Aug 2018 17:57:43 +0100
>>
>> On 08/28/2018 01:01 PM, SiZiOUS wrote:
>>> 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?
  

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

Le 29/08/2018 à 00:19, SiZiOUS a écrit :
> 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
>
> Le 28/08/2018 à 19:22, Eli Zaretskii a écrit :
>>> From: Pedro Alves <palves@redhat.com>
>>> Date: Tue, 28 Aug 2018 17:57:43 +0100
>>>
>>> On 08/28/2018 01:01 PM, SiZiOUS wrote:
>>>> 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?
>
  

On 2018-08-28 18:19, SiZiOUS wrote:
> 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?

> 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

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?

> 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!).

> 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
  

> Date: Wed, 29 Aug 2018 11:50:43 -0400
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>, Pedro Alves <palves@redhat.com>,
>         gdb-patches@sourceware.org
> 
> > 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.
  

>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:

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

Hi Simon!

Le 29/08/2018 à 17:50, Simon Marchi a écrit :
> On 2018-08-28 18:19, SiZiOUS wrote:
>> 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.
>
>> 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
>
> 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.
>
>> 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.
>
>> 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
  

Le 29/08/2018 à 18:24, Tom Tromey a écrit :
>>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:
>>> 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.
>
> Tom
  

On 08/29/2018 05:24 PM, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:
> 
>>> 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
  

On 08/29/2018 04:50 PM, Simon Marchi wrote:
> 
> 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
  

> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> 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.

> There seems to have been recent commits:
>   https://sourceforge.net/p/mingw/mailman/mingw-cvs/

Actually, the source tree is here:

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

On 08/29/2018 05:59 PM, SiZiOUS wrote:
> 
> 
> 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
  

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)

Le 29/08/2018 à 20:27, Pedro Alves a écrit :
> On 08/29/2018 05:59 PM, SiZiOUS wrote:
>>
>> 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
  

> From: SiZiOUS <sizious@gmail.com>
> Cc: gdb-patches@sourceware.org
> 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.