MinGW - Minimalist GNU for Windows

Fork

• mingw-dist
• build-aux
• wtklite
• pexports
• website
• mingw-get
• mingw-org-wsl
• mingw-pkgspecs

Donation

Reply To eliz

The latest version of GCC, 9.2.0, available for MinGW development, was released almost 2 years ago and last updated more than a year ago. Would it be possible to provide a MinGW port of a newer GCC version, like 10 or maybe even 11?

Given the will, anything may be possible, but who is going to develop, and maintain it?

Since retiring from my day job, nearly nine years ago, I have had no real need to use Windows for anything, beyond a desire to not see the MinGW.OSDN project, and its associated user community, die. However, that community cannot continue to depend on my solitary effort, indefinitely.

I did attempt to build GCC-10.2.0, around a year ago — I got as far as completing a GNU/Linux-hosted cross-compiler build, but ran into a brick wall, when trying to use that, to create a crossed-native Windows-hosted build. I've already posted regarding one issue arising. While that may not appear to be a show stopping issue, (other than for those users who want Ada support), I've since stumbled on to another, which is. When I compile any program — even a trivial "hello world" — with my MinGW-GCC-10.2.0 cross-compiler, and subsequently attempt to debug it, in GDB-9.2, on my Win7 virtual machine, I see:

Z:\> gdb foo.exe
GNU gdb (MinGW-GDB with Python 2.7.18) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
...
Reading symbols from foo.exe...
(gdb) start
Temporary breakpoint 1 at 0x4016b0: file foo.c, line ...
Starting program: Z:\foo.exe
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x4016a2

Command aborted.

So ... while I might like to offer a more recent GCC, unless someone else steps up to the plate, and undertakes the lion's share of the development and maintenance effort, then I'm sorry, but I have neither the time, nor the inclination to pursue this.

Reply To keith

Reply To eliz

The latest version of GCC, 9.2.0, available for MinGW development, was released almost 2 years ago and last updated more than a year ago. Would it be possible to provide a MinGW port of a newer GCC version, like 10 or maybe even 11?

Given the will, anything may be possible, but who is going to develop, and maintain it? Since retiring from my day job, nearly nine years ago, I have had no real need to use Windows for anything, beyond a desire to not see the MinGW.OSDN project, and its associated user community, die. However, that community cannot continue to depend on my solitary effort, indefinitely.

I see your point. Would you be willing to publish the procedure you were using for building GCC, including the configuration options, the rationale for using non-default options, and any notes and tricks that could be helpful for building future versions of GCC for MinGW? Maybe someone else could step up, if the bar was somewhat lower than starting from scratch.

I did attempt to build GCC-10.2.0, around a year ago — I got as far as completing a GNU/Linux-hosted cross-compiler build, but ran into a brick wall, when trying to use that, to create a crossed-native Windows-hosted build. I've already posted regarding one issue arising. While that may not appear to be a show stopping issue, (other than for those users who want Ada support), I've since stumbled on to another, which is. When I compile any program — even a trivial "hello world" — with my MinGW-GCC-10.2.0 cross-compiler, and subsequently attempt to debug it, in GDB-9.2, on my Win7 virtual machine, I see: {{{ Z:\> gdb foo.exe GNU gdb (MinGW-GDB with Python 2.7.18) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. ... Reading symbols from foo.exe... (gdb) start Temporary breakpoint 1 at 0x4016b0: file foo.c, line ... Starting program: Z:\foo.exe Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x4016a2 Command aborted. }}} From this point on, any attempt to step through the program, or to simply continue execution, (unless I delete all pending breakpoints), is denied — hardly useful for debugging. When the self-same program is compiled by my MinGW-GCC-9.2.0 cross-compiler, I see no such problems with GDB, on the Win7 VM.

Could this be due to Binutils? Maybe GCC 10 requires a newer version of Binutils than the one you have?

Does the program run normally when not debugged?

In any case, thanks for your efforts of maintaining MinGW for so many years.

I think it's possible to upgrade to GCC 9.4, it's still somewhat recent

Reply To eliz

Reply To keith

Given the will, anything may be possible, but who is going to develop, and maintain it?
Since retiring from my day job, nearly nine years ago, I have had no real need to use Windows for anything, beyond a desire to not see the MinGW.OSDN project, and its associated user community, die. However, that community cannot continue to depend on my solitary effort, indefinitely.

I see your point. Would you be willing to publish the procedure you were using for building GCC, including the configuration options, the rationale for using non-default options, and any notes and tricks that could be helpful for building future versions of GCC for MinGW? Maybe someone else could step up, if the bar was somewhat lower than starting from scratch.

I firmly believe that the maintainer needs to develop a solid understanding of the build process, and that isn't going to be achieved by simply repeating, parrot fashion, what I have done.

I use mingw-pkg to manage my builds, and yes, I would be willing to publish the package specification files, and patch sets, which I have used — in any case, they are already included in the MinGW.OSDN source tarballs for each of the packages which I have published. I am also prepared to answer any questions, from a prospective new maintainer, to help him/her to get up to speed.

I have also begun to create web pages — each a work-in-progress, rather incomplete, and as yet unpublished — to document mingw-pkg usage, and to describe how I set about using it to build a GNU/Linux hosted GCC cross-compiler. I could make them available, even in their incomplete state, as preview editions, if deemed desirable. (FWIW, my mingw-pkg build specifications, for both GCC and binutils, support building of both the cross-compiler, and native-compiler — crossed-native, for my builds — components, simply by adjustment of the mingw-pkg command line options).

Reply To wdlkmpx

I think it's possible to upgrade to GCC 9.4, it's still somewhat recent

There may be merit in this idea; thanks for the suggestion.

GCC-9.4.0 was published around a year ago, (and I suspect it may be the last of the GCC-9 series). Nonetheless, the release notes for both GCC-9.3.0, and GCC-9.4.0, suggest that they correct a significant number of regressions, within the earlier GCC-9 releases. Many of these regressions manifested as internal compiler errors, of which one, #40563, has already been reported against MinGW-GCC-9.2.0; if a point release upgrade is sufficient to correct even this one issue, it may be worth the effort.

I'll take a look, as time permits, but since my host compiler has now been upgraded to GCC-11.2.0 — courtesy of the Manjaro (Arch) Linux rolling release policy — I don't know how feasible it will be for me to build a point release of MinGW-GCC-9.4.0; (it is normally recommended that, when building a crossed-native GCC, the host compiler, and the intermediate cross-compiler, are at the same point release as the crossed-native compiler which is being built. If a working MinGW-GCC-9.4.0 cross-compiler cannot be built using the host GCC-11.2, then I would need to bootstrap a host-native GCC-9.4.0, which is a painful, and time-consuming exercise.

Reply To eliz

Reply To keith

[GDB unable to insert break-points in code compiled by mingw32-gcc-10.2.0 cross-compiler]

Could this be due to Binutils?

That's a possibility. I don't know, but thanks for the hint.

Maybe GCC 10 requires a newer version of Binutils than the one you have?

Maybe, but I did upgrade binutils, when I built the mingw32-gcc-10.2.0 cross-compiler. Right now, for mingw32-gcc-9.2.0, I have:

$ use mingw32-gcc-9.2.0
$ mingw32-gcc --version
mingw32-gcc (MinGW.org Cross-GCC Build-20200531-1) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ mingw32-as --version
GNU assembler (MinGW.org cross-GCC-9.2.0-1) 2.32
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `mingw32'.

$ use mingw32-gcc-10.2.0
$ mingw32-gcc --version
mingw32-gcc (MinGW.org Cross-GCC Build-1) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ mingw32-as --version
GNU assembler (MinGW.org Cross-Binutils Build-1) 2.36.1
Copyright (C) 2021 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `mingw32'.

Does the program run normally when not debugged?

AFAICT, it appears to, yes.

Reply To keith

[GDB unable to insert break-points in code compiled by mingw32-gcc-10.2.0 cross-compiler]

Today, I've built mingw32-binutils-2.38, so I'll install that into my mingw32-gcc-10.2.0 path, and advise whether or not it makes any difference.

Sadly, with:

$ use mingw32-gcc-10.2.0
$ mingw32-gcc --version
mingw32-gcc (MinGW.org Cross-GCC Build-1) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ mingw32-as --version
GNU assembler (MinGW.OSDN Cross-Binutils Build-1) 2.38
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `mingw32'.

On reflection, could it be due to a mismatch between the binutils version against which GDB was linked — IIRC, I built mingw32-gdb-9.2 using mingw32-gcc-9.2.0, with mingw32-binutils-2.32 — and the version used to build the target program — now mingw32-gcc-10.2.0, with mingw32-binutils-2.38? Some further investigation is required, I think.

Reply To keith

there is no improvement; GDB continues to be unable to insert break-points. On reflection, could it be due to a mismatch between the binutils version against which GDB was linked — IIRC, I built mingw32-gdb-9.2 using mingw32-gcc-9.2.0, with mingw32-binutils-2.32 — and the version used to build the target program — now mingw32-gcc-10.2.0, with mingw32-binutils-2.38? Some further investigation is required, I think.

If you can make that problematic executable available for download somewhere, I could try debugging it with the latest GDB 12.1 on MS-Windows, and see how far I get.

Also, maybe try using -gdwarf-2 when compiling the program, perhaps the problem is due to the debug info, not the executable code.

Reply To keith

[GDB unable to insert break-points in code compiled by mingw32-gcc-10.2.0 cross-compiler]

On reflection, could it be due to a mismatch between the binutils version against which GDB was linked — IIRC, I built mingw32-gdb-9.2 using mingw32-gcc-9.2.0, with mingw32-binutils-2.32 — and the version used to build the target program — now mingw32-gcc-10.2.0, with mingw32-binutils-2.38? Some further investigation is required, I think.

Yay! I rebuilt mingw32-binutils-2.32, and installed it into the mingw32-gcc-10.2.0 path, so I now see:

$ use mingw32-gcc-10.2.0
$ mingw32-gcc --version
mingw32-gcc (MinGW.org Cross-GCC Build-1) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ mingw32-as --version
GNU assembler (MinGW.org Cross-Binutils Build-1) 2.32
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `mingw32'.

The conclusion would seem to be that GDB needs to be linked with the same version of binutils as is used by the compiler which creates the programs which are to be debugged; thus, when we publish updated GCC/binutils combinations, it would seem that we need to simultaneously upgrade GDB, to avoid binutils (libbfd?) version mismatches.

Reply To eliz

Reply To keith

there is no improvement; GDB continues to be unable to insert break-points. On reflection, could it be due to a mismatch between the binutils version against which GDB was linked — IIRC, I built mingw32-gdb-9.2 using mingw32-gcc-9.2.0, with mingw32-binutils-2.32 — and the version used to build the target program — now mingw32-gcc-10.2.0, with mingw32-binutils-2.38? Some further investigation is required, I think.

If you can make that problematic executable available for download somewhere, I could try debugging it with the latest GDB 12.1 on MS-Windows, and see how far I get.

Sure. I've attached a tarball, containing the (trivial) source, together with two variants of the executable, both compiled with:

$ mingw32-gcc -g -O0 foo.c -o foo-gcc-10.2.0-binutils-2.3x.exe

Also, maybe try using -gdwarf-2 when compiling the program, perhaps the problem is due to the debug info, not the executable code.

-gdwarf-2 or -g makes no difference: binutils-2.32 is okay; binutils-2.38 is not.

Reply To keith

Sure. I've attached a tarball, containing the (trivial) source, together with two variants of the executable, both compiled with: {{{ $ mingw32-gcc -g -O0 foo.c -o foo-gcc-10.2.0-binutils-2.3x.exe }}} (with the respectively named binutils version installed in the mingw32-gcc-10.2.0 path). The binutils-2.32 variant (which uses the same binutils version as my GDB build) can be successfully debugged; the binutils-2.38 variant cannot.

Also, maybe try using -gdwarf-2 when compiling the program, perhaps the problem is due to the debug info, not the executable code.

-gdwarf-2 or -g makes no difference: binutils-2.32 is okay; binutils-2.38 is not.

Thanks. I unpacked the archive, and GDB 12.1 that I built myself can debug both executables without any trouble on native MS-Windows XPSP3. I've successfully stepped through both programs from start to exit.

So I think there's no problem with the compiler, just with the debugger you have there.

Reply To keith

I firmly believe that the maintainer needs to develop a solid understanding of the build process, and that isn't going to be achieved by simply repeating, parrot fashion, what I have done.

Yes, I agree. But reading patches and descriptions of configuration options used by someone experienced frequently gives ideas and focuses attention on important aspects of the build. It is not easy to find relevant optional features in the output of configure --help, and their short descriptions usually leave a lot of questions unanswered, and thus make the decisions regarding them difficult.

I use mingw-pkg to manage my builds, and yes, I would be willing to publish the package specification files, and patch sets, which I have used — in any case, they are already included in the MinGW.OSDN source tarballs for each of the packages which I have published. I am also prepared to answer any questions, from a prospective new maintainer, to help him/her to get up to speed. I have also begun to create web pages — each a work-in-progress, rather incomplete, and as yet unpublished — to document mingw-pkg usage, and to describe how I set about using it to build a GNU/Linux hosted GCC cross-compiler. I could make them available, even in their incomplete state, as preview editions, if deemed desirable. (FWIW, my mingw-pkg build specifications, for both GCC and binutils, support building of both the cross-compiler, and native-compiler — crossed-native, for my builds — components, simply by adjustment of the mingw-pkg command line options).

Thanks, I think this will be very useful, should Someone(TM) decide to step up.

Reply To eliz

So I think there's no problem with the compiler, just with the debugger you have there.

The debugger I have here is the same GDB-9.2 as can be found here; it was compiled from original GDB sources, with no patches applied. The only oddity is that the release encapsulates two distinct builds, one configured --with-python, and one --without-python, (with distinctly renamed gdb.exe variants), and the gdb.exe supplied is a simple wrapper, which delegates to one or other of the renamed variants, depending on whether, or not, a LoadLibrary() call can successfully load an appropriate python DLL.

I'm not convinced that there is actually anything wrong with my installed GDB; rather, I suspect that you were on the right track, when you pointed to a possible binutils issue. Both of the foo.exe variants, which I provided, were compiled by identically the same mingw32-gcc-10.2.0 cross-compiler, the only difference being in the version of binutils which was installed into that compiler's working path, at the time of compilation. I do note that, within the GDB-9.2 source tree, is an implementation of bfd which proclaims its version to be 2.33.50, (so presumably abstracted from binutils-2.33.50); thus, logically GDB-9.2 supports the ABI of bfd-2.33.50, (and maybe earlier). Realistically, I don't expect guaranteed forward compatibility with any more recent version of binutils, and sure enough, when I install binutils-2.32 — earlier than the GDB-9.2 bfd version — into the compiler's working path, I can successfully step through the resultant executables, in GDB-9.2; OTOH, when I install either binutils-2.36.1, or binutils-2.38 — both more recent than the GDB-9.2 bfd version — I cannot step through the resultant executables.

You can step through both of the executables, which I provided, with GDB-12.1. Presumably this more recent GDB supports a more recent bfd ABI — at least compatible with binutils-2.38, whilst remaining backward compatible at least as far as binutils-2.32. If this is indeed the case, I don't think that your ability to debug both of my executables is evidence of anything, other than an ABI (forward) compatibility issue.

Reply To keith

I'm not convinced that there is actually anything wrong with my installed GDB; rather, I suspect that you were on the right track, when you pointed to a possible binutils issue.

That's possible, of course. Is your GDB dynamically linked against any of the Binutils libraries, like libbfd or libopcodes? My GDB is linked statically against these libraries whose source comes within the GDB source tree. I also find it hard to believe that there could be such significant incompatibility between Binutils 2.33 and 2.38. I still have GDB 9.1 (also compiled locally on my system), and it, too, can step through your binaries with no problems. So I guess it's still somewhat a mystery.

I do note that, within the GDB-9.2 source tree, is an implementation of bfd which proclaims its version to be 2.33.50, (so presumably abstracted from binutils-2.33.50); thus, logically GDB-9.2 supports the ABI of bfd-2.33.50, (and maybe earlier). Realistically, I don't expect guaranteed forward compatibility with any more recent version of binutils, and sure enough, when I install binutils-2.32 — earlier than the GDB-9.2 bfd version — into the compiler's working path, I can successfully step through the resultant executables, in GDB-9.2; OTOH, when I install either binutils-2.36.1, or binutils-2.38 — both more recent than the GDB-9.2 bfd version — I cannot step through the resultant executables. You can step through both of the executables, which I provided, with GDB-12.1. Presumably this more recent GDB supports a more recent bfd ABI — at least compatible with binutils-2.38, whilst remaining backward compatible at least as far as binutils-2.32. If this is indeed the case, I don't think that your ability to debug both of my executables is evidence of anything, other than an ABI (forward) compatibility issue.

Yes, the version of bfd in the 12.1 tree identifies itself as 2.38.50.

Anyway, I think the main issue is resolved: the GCC 10 compiler you've built produces valid programs, and the issue with debugging seems to be unrelated to the compiler per se.

GCC 9.5 was released on may 27 https://gcc.gnu.org/pipermail/gcc/2022-May/238776.html

A distro with GCC 9 is Ubuntu focal https://packages.ubuntu.com/focal/gcc