Fortran support

[albertziegenhagel]

There are some port requests on the tracker that require a Fortran compiler to compile the respective libraries (#23, #233). I want to create this issue to start a discussion on how Fortran support could be brought to vcpkg.

Since Visual Studio does not come with a Fortran compiler, on Windows one usually uses one of the following

• Intel Fortran (ifort)
• gfortran through MinGW/MSYS

Intel Fortran is proprietary and thus may not be available for everyone but it has a nice Visual Studio integration which makes it pretty straight forward to consume libraries compiled with ifort from within Visual Studio.

gfortran on the other hand is free but does not have an integration into Visual Studio. In general one uses MinGW/MSYS to compile fortran libraries for windows when using gfortran. This comes with some implications:

• one can not use the Visual Studio generator in CMake but instead has to use some makefile system that is supported by MSYS (GNU Makefiles in general). As far as I know there is a special branch of ninja with fortran support maintained by kitware (https://github.com/Kitware/ninja) but I have no experience in using it and do not know how far the implementation is.
• The compiled libraries will be linked against the gcc and gfortran runtime libraries provided by MinGW.
• When compiling projects that include both Fortran and C or C++ code gcc/g++ is used to compile the C/C++ code instead of Visual C++.

So the first question would be which version should implemented in vcpkg:

1. Intel Fortran (in my opinion more easy to implement)
2. gfortran (may be preferred since it is free)
3. both (choice is always the best solution. Triplets could be used to determine which toolset to use)

I do not have a lot of experience in using gfortran on windows but I do have a port for netlib blas+lapack (http://www.netlib.org/lapack/) which works with some minor additional modifications to vcpkg itself when using Intel Fortran.

[traversaro]

As discussed in #233, at least initially I am for using Intel Fortran. However, I fear that requiring all the vcpkg users that want to install Fortran-dependent ports to buy the Intel Fortran compiler is a too much limiting. A possible workaround is to upload the binaries produced using Intel Fortran to a website and then let the port download them in binary form, as it is already done for ports such as tbb.

Perhaps Microsoft could provide some support for hosting such binaries produced by the community? @ras0219-msft @alexkaratarakis

[traversaro]

More in the long term, it would be interesting to see how the flang project for integrating a Fortan compiled in LLVM evolves. It was announced one year ago by PGI/Nvidia and it still not open source, but it is in progress. [1]
Considering LLVM compatibility with Visual Studio ABI, perhaps in a few years it could be a viable solution for vcpkg. : )

[1] : https://developer.arm.com/-/media/developer/developers/hpc/files/ARM-HPC-UG-SC16-PGI.pdf

[traversaro]

On the use of gfortran: checking Lapack documentation on how to build it on Windows I discovered of the GNUtoMS CMake property, described in this article regarding the improvement to Fortran support in CMake.

[ras0219-msft]

Requiring Intel Fortran for a complete out-of-the-box experience is definitely not desirable considering its licensing. However, it does look like it's a very popular (the most popular?) solution on Windows, so we should support it. This is exactly what triplets should do -- specify the toolchain and build parameters to be used for all built libraries.

We can totally handle tools that don't have VS IDE integration; we could easily download Ninja or use MSYS internally as long as we can produce crt-compatible libraries out the other side.

As for hosting prebuilt binaries -- assuming it is fine with the intel fortran license (I'm not too familiar on this point), we could very easily host them inside the NuGet gallery, treating the NuGet package as a simple zip archive of the prebuilt binaries. We even already have the capability to download the NuGet.exe tool (for the MSBuild per-project integration).

As has been mentioned many times elsewhere, building from source would be preferable for users who can (i.e. that have intel fortran), but it's better to have binaries than nothing at all -- as long as the fortran library doesn't have dependencies. We don't want the fact that library X required a binary drop to obstruct the maintainer of dependency Y from updating.

Edit: flang looks really promising! I'll look forward to whenever it gets enough fortran support to build the libraries we need :)

[albertziegenhagel]

The only thing I had to change to make it work with the Intel Compiler was to remove the extra arguments that are passed to "cmake --build" in vcpkg_install_cmake and vcpkg_build_cmake. This is because when the Visual Studio project files include Fortran code, "cmake --build" will invoke devenv.exe instead of msbuild.exe which will not understand the extra arguments.
Maybe an additional parameter that is passed to vcpkg_install_cmake and vcpkg_build_cmake to disable all extra arguments can be introduced (just like the one that has recently been introduced to disable the /m switch only).

The Intel compiler always got detected correctly by cmake automatically. I don't know whether this is the case under all circumstances (e.g. if you have multiple versions installed) but one could always set "CMAKE_Fortran_COMPILER" in the triplet. The problem would here would be to auto-detect and choose the correct paths to ifort.exe.

[traversaro]

As for hosting prebuilt binaries -- assuming it is fine with the intel fortran license (I'm not too familiar on this point), we could very easily host them inside the NuGet gallery, treating the NuGet package as a simple zip archive of the prebuilt binaries. We even already have the capability to download the NuGet.exe tool (for the MSBuild per-project integration).

Interesting read on this:
https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/626497 .

[traversaro]

I think that this approach #23 (comment) to packaging a fortran library such as LAPACK is relevant also here.

[traversaro]

The preliminary version of the flang compiler (based on PGI frontend) was open sourced in https://github.com/flang-compiler/flang . I don't think it is ready for use in vcpkg (I doubt there are binary availables) but it is an interesting reference.

[albertziegenhagel]

Very interesting! As far as I can see there is no official announcement available yet?!

I will go on and compile everything and try how far I can get with it. If it is just the missing binaries we may will be able to host the binaries ourselves somewhere.

[traversaro]

As far as I can see there is no official announcement available yet?!

Apparently no: http://www.phoronix.com/scan.php?page=news_item&px=LLVM-NVIDIA-Fortran-Flang .

[jakirkham]

Would be curious to hear about your experiences with Flang. We (at conda-forge) have been eyeing progress on it for some time (though it was only recently open sourced). In particular, we were looking at it for building things like OpenBLAS and SciPy, but inevitably including Fortran support for other things.

[traversaro]

Relevant flang issue on Windows support: flang-compiler/flang#143 .

[traversaro]

Good news regarding support for ucrtbase.dll support in mingw-w64 (see #1098 (comment) for a bit of background on this). If I understood correctly, at least partial support for ucrtbase.dll has been merged in the master branch :

• https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/1505134111-13637-2-git-send-email-martin%40martin.st/#msg36033731
• https://sourceforge.net/p/mingw-w64/mingw-w64/ci/bc6a87488995675ae80c312e3585cb1ace739b43/log/?path=

I don't know if this directly affects the libraries built with gfortran, and when this will be available in a released version of mingw-w64 .

[albertziegenhagel]

This sound like great news!

The PR at #1098 already includes MinGW+w64 support, but it requires the not yet released version of CMake 3.10 to support GnuToMS for the Ninja generator and of course has the known problems of linking against msvcrt.

I am really looking forward to a release version of MinGW that includes the final ucrt suppprt.

[ghost]

Ironically, using vcpkg to build flang would be the most time-efficient method to get a fortran compiler with MSVC ABI compatibility. But, MSVC does not have OpenMP 4.0, which flang requires. So essentially, the steps would be:

1. Add clang support to vcpkg (clang has ABI compatibility with MSVC and supports OpenMP 4.0).
2. Fill in the required libraries (specifically, clang-flang, which is a modified clang)
3. Add openmp-llvm to the ports.
4. Use vcpkg to install the libraries and then build flang with MSVC.

Now whether this will actually happen is a different story. MSFT might not want to add clang support to this project because then people may obviously not use their compiler. But based on their responses, there is little chance of MSVC adding OpenMP 4 support.

In other words, this is technically solvable, but when business interests / people come into the picture it might not be (and I have nothing against MSFT; I think it's a good company and I think this is an excellent project that was long overdue).

[albertziegenhagel]

@xoviat have you tried to build flang for windows with the described method manually? And then use that flang binary to build any fortran code on windows? As far as I understood, flang does not yet support windows at all (not only being build by MSVC, but in general. Correct me if I am wrong!).

[ghost]

Flang supports windows but someone just needs to build it, which is not trivial for the same reason that vcpkg exists.

[jakirkham]

If that's true, why aren't there any updates in issue ( flang-compiler/flang#143 )? Where has this work been occurring?

[ghost]

No one has built it yet but it's "just" CMake.

[ghost]

Actually, after reconsidering the problem, it's possible to override the generator with a PreLoad.cmake. If my theory is correct, then we don't actually need MSFT to modify the tool sources to build openmp-llvm. I think we have a viable path forward.

So to summarize, we need ports for:

• openmp-llvm
• clang-flang

If someone else wants to port one of these, then I may port the other.

[muemart]

i don't think even ports are necessary. We could just precompile flang and treat it like one of the external tools, and then use it like that. Though I'm not sure if flang is actually buildable on Windows, even with msys2 and friends.

[ghost]

Though I'm not sure if flang is actually buildable on Windows, even with msys2 and friends.

Let me be clear: flang is buildable on windows, but it has a complex dependency chain, which is the exact problem that vcpkg was designed to solve. The only problem is that one dependency is openmp-llvm, which MSVC can't build. However, it appears that the default generator can be overridden, making it buildable with once the above libraries are ported.

We could just precompile flang

Yes, but precompiling is the problem. The libraries aren't there yet. But they could be with vcpkg.

[jakirkham]

LLVM's openmp is definitely buildable on Windows. We build it in conda-forge currently.

ref: https://github.com/conda-forge/openmp-feedstock

[ghost]

With MSVC?

[albertziegenhagel]

Sorry for the delay, but I've now updated the PR to download the new version from conda-forge.

Btw: I could build LAPACK and ScaLAPACK with flang, but when I try to compile MUMPS it fails with a message about a missing header, although on the first look it seems that the correct include path is set. If you want to try it yourself:

• checkout the branch fortran-ports from https://github.com/albertziegenhagel/vcpkg/tree/fortran-ports
• Add set(VCPKG_FORTRAN_COMPILER Flang) to the triplet file
• Make sure a current CMake build is in your PATH
• Try vcpkg install mumps

[atkawa7]

@albertziegenhagel Thank you for your work on integrating fortran on vcpkg. Just wondering if you were able to make fortran work. @ras0219-msft Regarding the choice of the fotran compiler. Shouldn't we leave that decision to the user. I prefer using intel fortran compiler. So if we choose flang it feels as if vcpkg has locked us in.

[albertziegenhagel]

@atkawa7 I am using fortran libraries build via vcpkg locally all the time through #1098. There you have the option to select the fortran compiler in the triplet file with currently Intel, PGI, GNU (MinGW gfortran) and Flang as options (with the last two being experimental). I would prefer to keep those options available. Flang can be used as a default, since it is free and promises to have the best compatibility with the rest of the "msvc environment".

[claudiofantacci]

Hi everyone, how is this PR evolving?
Is there any chance to see #1098 going through 😄?

[traversaro]

I obviously cannot speak for vcpkg mantainers, but I guess one of the reasons #1098 cannot be merged is that it three out of the four supported compilers cannot be maintained in a "clean" way (please correct me if I am getting something wrong):

• Intel : It is not possible to maintain/debug problems, unless you have the (relatively expensive) license for it.
• Flang : The Windows version shipped through conda is a fork of upstream flang, that itself requires a fork of upstream llvm and clang. I saw that now work has started on f18 (https://github.com/flang-compiler/f18), a modern fortran compielr that aims for upstream llvm integration, but I guess it will take years to be completed and integrated upstream.
• PGI : The main problem there is the 1 year time-bomb condition discussed in Fortran support #1098 (comment) and the related EULA.

Do not get me wrong, I am a huge fan of the work of @albertziegenhagel , I just suspect these are the reasons why it can't be integrated upstream, and I thought it could be useful to have recap of them at this moment.

The only remaining option is GNU (MinGW gfortran), that back in time had the major drawback on not being able to link to the ucrt runtime library used since VS2015, and it required instead an older crt, see #485 (comment) . I recently checked on the Mingw-w64 website, and apparently in the last year they had several releases that improved support for linking with ucrt (thanks to the amazing work of @mstorsjo), see for example https://mingw-w64.org/doku.php and https://sourceforge.net/p/mingw-w64/mailman/message/36416777/ . If someone is interested in streamlining Fortran support in upstream vcpkg, perhaps it could make sense to try to update @albertziegenhagel's fork to use the latest Mingw-w64 to see if the ucrt support is advanced enough to produce usable fortran libraries, or if there are other tricky issues.

[fcooper8472]

@traversaro thanks for summarising. It looks as though there is at least some problem with each of the four options of Intel, Flang, PGI, and GNU.

Surely, though, some fortran support is better than no fortran support? I have successfully used @albertziegenhagel's fork in the past, and it would be great to integrate that functionality properly into vcpkg.

Why, for instance, does the issue you raise with Flang prevent it being a perfectly adequate solution for vcpkg?

[traversaro]

Some interesting recent discussion related to this issue:

• Building scipy isuruf/flang#129 (comment) : Recent discussion in the Python community on a Fortran UCRT-compatible, involving the same people behind the conda's Flang port (cc @rgommers that may be interested in this discussion)
• http://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html : RFC for comment for moving the development of the new experimental f18 Fortran LLVM front-end to LLVM upstream. The front-end is not a currently able to generate code (see http://lists.llvm.org/pipermail/llvm-dev/2019-March/130694.html for an update on a current progress) but in the long-term it could be a good solution.
• In the f18 llvm-dev thread, they posted a link to http://fort-compiler.org/, another Fortran front end for LLVM that I had never heard of.

[traversaro]

http://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html : RFC for comment for moving the development of the new experimental f18 Fortran LLVM front-end to LLVM upstream. The front-end is not a currently able to generate code (see http://lists.llvm.org/pipermail/llvm-dev/2019-March/130694.html for an update on a current progress) but in the long-term it could be a good solution.

http://lists.llvm.org/pipermail/llvm-dev/2019-April/131703.html
The f18 Fortran LLVM front-end will be integrated in LLVM upstream.

[gmanlan]

@ghost: is the flang win32 version actually 32 bit or you mean x64? conda-forge has dropped support for Windows 32 bit so only 64 bit packages can be found. Have you produced a 32 bit version of flang? If so, it is published through a conda channel or available as a standalone tar?

I have tried the channel isuruf/label/flang but no luck.

[isuruf]

@gmanlan, it's x64. flang doesn't support 32 bit version.

[traversaro]

PR #12805 by @Neumann-A merged in vcpkg upstream a minimal support for building fortran packages using gfortran . I guess that using this infrastructure it should be possible to add more fortran ports. An open point (at least for me, perhaps someone else has a more clear picture) is the old issue regarding gfortran that was producing libraries that linked msvcrt, while vcpkg required libraries that linked ucrt . The 7.0.0 version of mingw-w64 comes with UCRT support ( https://sourceforge.net/p/mingw-w64/mailman/message/36804945/ ), but I am not sure if the gfortran used in #12805 indeed links against ucrt .

[albertziegenhagel]

I guess that using this infrastructure it should be possible to add more fortran ports

I am currently working on updating all fortran ports from my old branch to the new fortran support and will open MRs to upstream vcpkg as soon as most of the things are working.

I do currently have a working port for ScaLAPACK. SuperLU_Dist and MUMPS are blocked by linking issues related to the CRT. I am suspecting that it is exactly the problem that you are describing above, but I am not sure yet.

Ports for PETSc and SLEPc are more or less ready, but have not yet been tested with SuperLU_Dist and MUMPS as dependencies, because of the problems described above.

[traversaro]

I guess that using this infrastructure it should be possible to add more fortran ports

I am currently working on updating all fortran ports from my old branch to the new fortran support and will open MRs to upstream vcpkg as soon as most of the things are working.

Thanks a lot, this is great news!

SuperLU_Dist and MUMPS are blocked by linking issues related to the CRT. I am suspecting that it is exactly the problem that you are describing above, but I am not sure yet.

I am afraid indeed it is, I remember that back in time MUMPS was the port for which I first experienced the problem. I looked into that in the past, and unfortunately as far as I understood the choice of CRT to use in mingw-w64 (and hence in gfortran) needs to be done at mingw-w64 compilation time, by passing the option --with-default-msvcrt=ucrt (see https://stackoverflow.com/questions/57528555/how-do-i-build-against-the-ucrt-with-mingw-w64#comment110354007_58857816 and https://github.com/niXman/mingw-builds/blob/7f9ed8fd7fb221ba81d957602c7adc67b97b1341/build#L73). If the binaries of gfortran that we currently use instead use some other crt, then I am afraid we need to find another gfortran build or build our own.

Note that in theory, if there is no memory allocated by one crt that is then passed across library boundaries to be freed by the user code (or vice versa) in theory the library should work fine even by linking the old CRT, but that is always risky, because assessing all the use of dynamically allocated memory in a complex library is far from trivial.

[albertziegenhagel]

I was able to make use of the UCRT via a spec file. If I understand correctly, this should be sufficient for libraries that do use only C and Fortran, and rebuilding mingw with --with-default-msvcrt=ucrt is only required when you want to use C++, because of libstc++ being linked against msvcrt, right?

I think using g++ for C++ will be problematic anyways because of its use of libstdc++, when all other ports will be build by msvc, linking against the Microsoft STL, so there is nothing we can do about it anyways?!

[traversaro]

I was able to make use of the UCRT via a spec file. If I understand correctly, this should be sufficient for libraries that do use only C and Fortran, and rebuilding mingw with --with-default-msvcrt=ucrt is only required when you want to use C++, because of libstc++ being linked against msvcrt, right?

That is a good point, I never realized that. If that is the case, then everything is indeed easier.

[Neumann-A]

Just an idea: add a port for gcc and build libgfortran from source via maybe clang-cl? Then you can play with the CMake platform build rules to adjust everything to link/build correctly.

[albertziegenhagel]

That is a good point, I never realized that. If that is the case, then everything is indeed easier.

Hm, seems that I was wrong.
While LAPACK seems to link to the correct CRT:

PS C:\vcpkg> dumpbin /DEPENDENTS C:\vcpkg\installed\x64-windows\bin\liblapack.dll
Microsoft (R) COFF/PE Dumper Version 14.27.29111.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file C:\vcpkg\installed\x64-windows\bin\liblapack.dll

File Type: DLL

  Image has the following dependencies:

    KERNEL32.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-private-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    libgcc_s_seh-1.dll
    libgfortran-5.dll
    openblas.dll

The MinGW libraries still link to MSVCRT:

PS C:\vcpkg> dumpbin /DEPENDENTS C:\vcpkg\installed\x64-windows\bin\libgcc_s_seh-1.dll
Microsoft (R) COFF/PE Dumper Version 14.27.29111.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file C:\vcpkg\installed\x64-windows\bin\libgcc_s_seh-1.dll

File Type: DLL

  Image has the following dependencies:

    KERNEL32.dll
    msvcrt.dll
    libwinpthread-1.dll

Just an idea: add a port for gcc and build libgfortran from source via maybe clang-cl? Then you can play with the CMake platform build rules to adjust everything to link/build correctly.

Maybe this is what we have to do.
@traversaro I just found https://github.com/traversaro/mingw-w64-ucrt-builds. Does this already provide a working version of mingw, configured to use the UCRT?

edit: when I further think about this, I don't think that using gfortran from MinGW will be a sufficient solution for all ports, even with the working UCRT linkage. I don't think we will be able to make libraries that use both, Fortran and C++ ever work. The GNU toolchain and MSVC are using different object formats, so you can not link an object generated by cl and an object generated by gfortran with any of the linkers. That is why we currently have to use gcc and g++ when we want to use gfortran, but since g++ does only support libstdc++ we will never be able to use the C++ libraries that are compiled with MinGW in combination with libraries compiled compiled by cl.

I think if one wants to use gfortran on windows, one would have to use one of mingw triplets...

[traversaro]

@traversaro I just found https://github.com/traversaro/mingw-w64-ucrt-builds. Does this already provide a working version of mingw, configured to use the UCRT?

Unfortunately no, it was an early and unsuccessful test.

I don't think we will be able to make libraries that use both, Fortran and C++ ever work.

I guess this is a problem just for mixed projects, right? I guess those were exactly the one for which the GNUtoMS target and the CMakeAddFortranSubdirectory CMake functions were developed, to build C++ and Fortran parts of a mixed project as a separate projects, and then link them together?

[albertziegenhagel]

I guess those were exactly the one for which the GNUtoMS target and the CMakeAddFortranSubdirectory CMake functions were developed, to build C++ and Fortran parts of a mixed project as a separate projects, and then link them together?

Yes, i think so. But if I understand those tools correctly, this would require support from the library to be build e.g. SuperLU_Dist or a big amount of patching from the port author. For a library like PETSc that does not use CMake it will be even more difficult if not even close to impossible.

[traversaro]

I guess those were exactly the one for which the GNUtoMS target and the CMakeAddFortranSubdirectory CMake functions were developed, to build C++ and Fortran parts of a mixed project as a separate projects, and then link them together?

Yes, i think so. But if I understand those tools correctly, this would require support from the library to be build e.g. SuperLU_Dist or a big amount of patching from the port author. For a library like PETSc that does not use CMake it will be even more difficult if not even close to impossible.

I see, yes, for those case gfortran even with ucrt support is not a convenient solution.

[albertziegenhagel]

The interesting thing is that I was actually able to build some C++ code with cl and link it to Fortran code build by gfortran with link.exe.

// main.cpp
#include <iostream>

extern "C" {
void fortran_print_();
}

int main()
{
    std::cout << "Hello C++" << std::endl;
    fortran_print_();
    return 0;
}

!      fortran.f90
       SUBROUTINE FORTRAN_PRINT( )
       Print *, "Hello Fortran!"
       END

Can be compiled and run by:

PS> cl -c .\main.cpp /EHsc
PS> gfortran -c .\fortran.f90
PS> link .\main.obj .\fortran.o libgfortran.dll.a
PS> .\main.exe
Hello C++
 Hello Fortran!

So I am not sure yet where the limitations exactly are. Next thing I will try is to make the same project build with CMake.

[BillyONeal]

I note that there are ports using fortran at this time so the original issue filing appears to be resolved, but as you note above there are still some 'holes' in that support. You might want to consider opening issues for the specific CRT problems above to make it easier for folks familiar with this problem space to find. I'll leave this open for now though.

[Neumann-A]

Since Intel OneAPI is freely available now and includes the intel fortran compiler ifort we should try to switch from gfortran to ifort if it is possible to install Intel OneAPI on the CI machines. This should in theory cleanly resolve the CRT problems.

[traversaro]

For what regards CRT problems, I recently noticed that msys2 now provides ucrt-based builds on top of the already existing MINGW64 builds: https://packages.msys2.org/package/mingw-w64-ucrt-x86_64-gcc-fortran?repo=ucrt64 . If people are still interested in this, a possible strategy may be to switch the vcpkg-gfortran port (added in #12805) to use the ucrt gfortran version.