Fix parsing of gfortran version

[apaz-cli]

No description provided.

[apaz-cli]

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.

[vtjnash]

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

[apaz-cli]

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.

[ViralBShah]

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.

[staticfloat]

It is still selecting the last thing that matches, I believe.

[staticfloat]

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.

[staticfloat]

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.

[gbaraldi]

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

[vtjnash]

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

[vtjnash]

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

[ViralBShah]

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)?

[staticfloat]

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.

[vtjnash]

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

[vtjnash]

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

[vtjnash]

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.

[apaz-cli]

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

[vtjnash]

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

[staticfloat]

Looks good to me!