From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110821 invoked by alias); 29 Aug 2018 16:59:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 110808 invoked by uid 89); 29 Aug 2018 16:59:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=enthusiasm, workstation, golden, H*c:alternative X-HELO: mail-wr1-f54.google.com Received: from mail-wr1-f54.google.com (HELO mail-wr1-f54.google.com) (209.85.221.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Aug 2018 16:59:33 +0000 Received: by mail-wr1-f54.google.com with SMTP id v17-v6so5493274wrr.9 for ; Wed, 29 Aug 2018 09:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=AdhaVoTFj7BiMwGsQjMiJG9pRq1ODm5u9uvQ6gHHjlo=; b=msy4B1GVTiBUz788/W5wIi3QgG0RvQozKFNeixapgIgNZuhiKQ4NBFEsD7EU3MFaAX FC95iaVQBk+TDZhnq+MXRBKAXqmEggyOZYYp5NJ9bCw14H+8qT5JvfHK1qc7InLY/Hyb dJ6XPI9ZERD41VSjQLQY3JCqNir6EQzOV0d1GH6B7/ZGz/cW+BOrqS9cttudtrzSI3kL JNrQPPv04OOpnfhVwBg+jssvfYrUqcBgOFAwFmfMNHCY9Fu9TRlvPINq7/K9tFwRcktD QTPX3wvobxRdoBLmyKMPgFvwmGiMlIU/HQvwvaXc0W/3lYS5i9vFP7Y1tTFkNnp4DTOH 4ADw== Return-Path: Received: from ?IPv6:2a01:e35:2eac:2a80:7c7d:2022:97ba:9bab? ([2a01:e35:2eac:2a80:7c7d:2022:97ba:9bab]) by smtp.gmail.com with ESMTPSA id a6-v6sm6208217wmf.22.2018.08.29.09.59.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 09:59:30 -0700 (PDT) Subject: Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue To: Simon Marchi Cc: Eli Zaretskii , Pedro Alves , gdb-patches@sourceware.org References: <56c5911c-e0ba-5a17-64bb-3634af60a07d@gmail.com> <18eaf339-ca0a-061c-4a17-b837e6ef81a2@redhat.com> <83wosa2yos.fsf@gnu.org> <56153263-c5e6-45ce-8629-c5a77cf17f5b@gmail.com> From: SiZiOUS Message-ID: <92136d29-0bec-7fcf-23c6-26dd4608dbd8@gmail.com> Date: Wed, 29 Aug 2018 16:59:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-08/txt/msg00755.txt.bz2 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