Fortran support #19059
Replies: 74 comments
-
|
As discussed in #233, at least initially I am for using Intel Fortran. However, I fear that requiring all the Perhaps Microsoft could provide some support for hosting such binaries produced by the community? @ras0219-msft @alexkaratarakis |
Beta Was this translation helpful? Give feedback.
-
|
More in the long term, it would be interesting to see how the [1] : https://developer.arm.com/-/media/developer/developers/hpc/files/ARM-HPC-UG-SC16-PGI.pdf |
Beta Was this translation helpful? Give feedback.
-
|
On the use of |
Beta Was this translation helpful? Give feedback.
-
|
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 :) |
Beta Was this translation helpful? Give feedback.
-
|
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. 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. |
Beta Was this translation helpful? Give feedback.
-
Interesting read on this: |
Beta Was this translation helpful? Give feedback.
-
|
I think that this approach #23 (comment) to packaging a fortran library such as LAPACK is relevant also here. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Apparently no: http://www.phoronix.com/scan.php?page=news_item&px=LLVM-NVIDIA-Fortran-Flang . |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Relevant flang issue on Windows support: flang-compiler/flang#143 . |
Beta Was this translation helpful? Give feedback.
-
|
Good news regarding support for
I don't know if this directly affects the libraries built with |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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). |
Beta Was this translation helpful? Give feedback.
-
|
PR #12805 by @Neumann-A merged in vcpkg upstream a minimal support for building fortran packages using |
Beta Was this translation helpful? Give feedback.
-
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 Ports for |
Beta Was this translation helpful? Give feedback.
-
Thanks a lot, this is great news!
I am afraid indeed it is, I remember that back in time 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. |
Beta Was this translation helpful? Give feedback.
-
|
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 I think using g++ for C++ will be problematic anyways because of its use of |
Beta Was this translation helpful? Give feedback.
-
That is a good point, I never realized that. If that is the case, then everything is indeed easier. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Hm, seems that I was wrong. The MinGW libraries still link to MSVCRT:
Maybe this is what we have to do. 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 I think if one wants to use |
Beta Was this translation helpful? Give feedback.
-
Unfortunately no, it was an early and unsuccessful test.
I guess this is a problem just for mixed projects, right? I guess those were exactly the one for which the |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
I see, yes, for those case gfortran even with ucrt support is not a convenient solution. |
Beta Was this translation helpful? Give feedback.
-
|
The interesting thing is that I was actually able to build some C++ code with // 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!"
ENDCan be compiled and run by: 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
For what regards CRT problems, I recently noticed that msys2 now provides ucrt-based builds on top of the already existing |
Beta Was this translation helpful? Give feedback.
-
|
So where should we go with the fortran support. There are some possibilities a) Use ifort (#19413) -> requires users to install intel oneapi -> only supports x86/x64; no uwp |
Beta Was this translation helpful? Give feedback.
-
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 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:
So the first question would be which version should implemented in vcpkg:
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.
Beta Was this translation helpful? Give feedback.
All reactions