I'll return to this, probably want to rewrite the regex more completely to make sure it's sane, but this is enough to solve my issue for now.

Could you add your example gfortran --version output to the thread here for demonstration?

This is what x86_64-w64-mingw32-gfortran-posix --version gives me.

GNU Fortran (GCC) 10-posix 20220324
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.

Mine is:

PS C:\Users\viral\julia> x86_64-w64-mingw32-gfortran --version
GNU Fortran (GCC) 11.3.0
Copyright (C) 2021 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.

IMO it’s a little unreasonable to parse the version number 10-posix. There’s no way we can realistically disambiguate whether 10-posix is the version number, or 20220324 is. I think we should require at least one period in the version number.

If it can’t be auto detected, we should have a good error message, or just default to libgfortran5, since that is by far the most common these days.

Could we anchor the version search by finding (GCC) and going right from there? Or are there some where it doesn't do that?
We can't :). At least not trivially

gfortran --version
GNU Fortran (Homebrew GCC 12.2.0) 12.2.0

Looked into this more, and it appears that --version doesn't really print the version, but some other random stuff. But rather -dumpversion does print the version:

$ gfortran -v 2>&1 | grep 'gcc version'
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) 

gfortran -dumpversion
9

or

$ gfortran -dumpspecs | grep -C1 "^\*version:\$"

*version:
9.4.0

We can't :). At least not trivially

Possibly not even non-trivially haha:

$ gfortran --version
GNU Fortran (MacPorts gcc11 11.3.0_4+stdlib_flag) 11.3.0

If we don't need gfortran to build, why bother looking for it (at least for users who are doing the default and using BB for all the dependencies)?

If we don't need gfortran to build, why bother looking for it (at least for users who are doing the default and using BB for all the dependencies)?

Because if they have a gfortran locally, anything they build with that gfortran will be locked to a particular ABI. We need to know what ABI that is, so that Julia's dependencies (e.g. OpenBLAS) use the same ABI.

Wow, who would have thought this too could still have so many problems with it

For example:
ValueError: invalid literal for int() with base 10: 'gcc (GCC) 9.1.0'

Or in other cases trying to interpret the Apple version of clang as a gfortan compiler

Apparently supporting newer versions need gcc -dumpfullversion -dumpversion according to stack overflow

The various dump flags are defined here (for their current form, after getting renamed in gcc-8) https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Developer-Options.html#Developer-Options

If all else fails, we can get the all cpp macros with -dM -E and search for __GNUC__ in them. That API at least has been around and reliable for a long time.

Is there a case where the major version number would ever not be the first number in gfortran -dumpversion?

Yes, the docs clarify that this was changed from being the fullversion to being the filepath name