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