Yep, flang 5.0.0.
Ooo nice! I will try that too.
Conda-forge has GFortran/MinGW, I think it is based on an early attempt to distribute MSYS2 via conda. What you get is GCC 5.3.0 and can be somewhat shaky depending on the features you want to use in modern Fortran.
Alternatives, beside the quickstart installer might be
This thread is relevant for the status of Fortran on conda-forge:
This is terrific!! Worked great for me. I might just use it. Thanks again!
I wonder why it is so difficult to get a recent gfortran into conda-forge? I say this knowing almost nothing about how conda-forge works.
Nobody decided to do it yet, simple as that. It is not a nice task, you will have to patch the compiler until it passes its test suite, than you have to rebuild all existing packages using this compiler (only in case of an ABI change), if something fails probably patch the package build and/or the compiler build.
It just takes a lot of effort and conda-forge is just like Fortran-lang entirely driven by volunteers. Helping hands are always welcome!
The workflow for a compiler update on conda-forge is outlined in
Another choice may be using Docker. You can install and configure whatever you want in the Docker image. People just need to load that image and bingo.
Or, I think you can also create a WSL image with GUI configured, and people can load that WSL image, and visit it using Windows Remote Desktop via the port you defined in that image (such as port 3389, 3390, etc).
But of course, in the above two cases, users are still using Linux actually. But Gfortran performs the best in Linux.
If you make the students use Visual Studio Code it should be able to integrate natively with the WSL environment, no virtualization from within WSL. BTW The same is true for docker images, although you might need the remote extension pack from Microsoft
I think it has to be as easy as Python or Julia. I can’t tell beginners they have to install Linux in order to use Fortran on Windows.
I always recommend MSYS2 (
winget install msys2.msys2), because in addition to the GCC suite, we may also need other tools, such as
python, etc., which can be easily obtained in MSYS2. After installing MSYS2, we only need to set the the environment path of the execution program can be:
C:\msys64\ucrt64\bin, that you can access the MSYS2 environment in
Other than that,
winget install Cygwin.Cygwin) is also possible, but as far as I know, MSYS2 seems to be based on
Cygwin under the hood, so I think there may be no essential difference between MSYS2 and
Cygwin, but MSYS2 is more convenient.
Cygwin has a much more complete *nix environment easily available with hundreds (thousands?) of additional packages and X11 Windows; but with the other options available and depending on whether you also do/do not want them to have a Unix-like interface and X11 windows it might not be what you want. I adore it, but there are a lot of other options, as mentioned. Works great with fpm(1) too, but so do some of the others.
Thank you for that. I totally understand it that volunteers don’t always want to do the thankless tasks! I wonder if some of the ongoing activities to try and get funding could be applied to this? Being stuck with older compilers is a continuing problem for the Fortran ecosystem, and Windows is an important platform for beginners, students, and potential corporate users.
Anyway, a question: what if we just wanted a gfortran we could
conda install, but don’t care about recompiling all the existing packages? Would that be a smaller task? The gfortran used by
quickstart-fortran is from WinLibs. Maybe I could create some recipe to just dump it in an env? Or does that not make any sense? For my classroom example, I just want a conda env file that will install a recent gfortran, python, and probably matplotlib (so I can use
pyplot-fortran to show how to plot from Fortran), maybe a couple other things. Would the presence of a rogue gfortran in the conda environment conflict in some way with what was used to compile some of the libraries (numpy or lapack maybe)?
I haven’t touched compilers yet on conda-forge, I can’t tell for sure if this would be easier. They are mostly split packages, with a compiler, a wrapper and a runtime. The issue is the runtime which might not be compatible with older versions and therefore conflicts with installations of older runtime versions.
The rebuilding after such an update is mostly automated, the problem are the 5% of packages which might fail, those can be mostly fixed in the respective package recipe. Since we are talking about 17k packages on conda-forge and an update affecting the fraction which uses GCC for C, C++ and/or GFortran and Windows, it is best to coordinate such effort with the conda-forge core team.
I think Brecht Sanders never shared his setup for building WinLibs.
Conda environments provide enough isolation to make this work. You can have completely different and conflicting runtimes for some programs if you have them in different environments, then you can just stack them on top of each other and things should usually work. Cross-linking or cross-loading libraries between such environments will be a bit more tricky as you try to break the environment isolation.
At GFortran - GCC Wiki several options to download gfortran binaries are discussed. I have not tested these downloads (on Windows I use MSYS2). Note that for these solutions OpenCoarrays usually is not included, so the use of Coarrys may be be limited to a single image.
From what I could find, the only package which seems to be up-to-date (12.2.0) and self-contained (no WSL/MSYS2/etc. needed) is from Equation.com. As a bonus, it includes gdb, make, OpenMP.
I do not use Windows, however, so I have no idea whether it really works.
Now opencoarray also supports Windows-gfortran. With the support of Intel oneAPI mpi^3.0, this is a new feature that was implemented in the first half of this year. I have successfully tested it before, but I have no need to actually use mpi/coarray.
We just finished a MOM6 workshop and many Windows users successfully used Ubuntu WSL, which did not require Conda.
It was the Macs which gave us the most trouble, especially from undesired Conda-Homebrew interaction. Windows and Linux were mostly pain free.
I use a macOS and I do not use Homebrew, as it sets up all kinds of stuff systemwide. The GFortran in conda-forge segfaults sometimes. I install GFortran using Spack, and that seems to work pretty well.
I just started using Homebrew a few months ago on Macs. Before that, for the past 20 years, I have been using the fink package manager. Homebrew on Apple arm64 hardware installs in its own place within /opt. Homebrew on intel hardware installs in /usr. I much prefer the former, even though you need to change PATH.
FYI: It turns out, the Fortran Playground was perfect for this. Obviously, not ideal for anything complicated, but for showing beginners basic stuff, it was great!