public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: SiZiOUS <sizious@gmail.com>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: Eli Zaretskii <eliz@gnu.org>, Pedro Alves <palves@redhat.com>,
	gdb-patches@sourceware.org
Subject: Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue
Date: Wed, 29 Aug 2018 16:59:00 -0000	[thread overview]
Message-ID: <92136d29-0bec-7fcf-23c6-26dd4608dbd8@gmail.com> (raw)
In-Reply-To: <a43edf5c45fbc74d7708a851f4d8d1dd@polymtl.ca>

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

  parent reply	other threads:[~2018-08-29 16:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-28 12:01 SiZiOUS
2018-08-28 16:57 ` Pedro Alves
2018-08-28 17:22   ` Eli Zaretskii
2018-08-28 22:19     ` SiZiOUS
2018-08-29  8:04       ` SiZiOUS
2018-09-09 20:06         ` Eli Zaretskii
     [not found]           ` <ddb12e03-7fc3-bf4b-cd24-235b43c33d38@gmail.com>
2018-12-02 13:52             ` SiZiOUS
2018-08-29 15:50       ` Simon Marchi
2018-08-29 16:19         ` Eli Zaretskii
2018-08-29 16:25         ` Tom Tromey
2018-08-29 17:01           ` SiZiOUS
2018-08-29 17:46           ` Pedro Alves
2018-08-29 16:59         ` SiZiOUS [this message]
2018-08-29 18:27           ` Pedro Alves
2018-08-29 21:07             ` SiZiOUS
2018-08-29 17:54         ` Pedro Alves
2018-08-29 18:09           ` 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=92136d29-0bec-7fcf-23c6-26dd4608dbd8@gmail.com \
    --to=sizious@gmail.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=simon.marchi@polymtl.ca \
    /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).