Nobody currently working on LFortran actually uses Windows, which is causing us to struggle with getting it to link executables properly on that platform. If there’s anybody on this forum who is experienced with doing Fortran development on Windows and who might be willing to advise us on this?
We aren’t writing our own linker or anything terribly difficult like that - we just need to get LFortran to correctly invoke the platform linker to turn object files into executables.
It’s almost there, but not quite. Update: this issue is now fixed. I am very happy about that, LFortran can now create standalone executables on Windows using the usual:
I don’t have a Windows machine, so I only debug it at the CI, which has about 10 min iterations, so it takes a long time. If somebody here uses Windows and has time to help, that would be very helpful. I can help with any LFortran’s internals, just need somebody to try to get it to link.
I use Windows but am not familiar with cmake. If you want me to take a look, I’ll need instructions on what is needed to show the problem.
As for your first problem, Windows compilers typically add linker default library directives to the object file, that name the runtime libraries to link against. If you use the command: dumpbin -directives foo.obj
(this assumes you have the MSVC tools in your environment) it will show you the directives in foo.obj. Try this on an ifort-compiled object to see. This has the advantage of not requiring the user to name all of the libraries needed. It has the disadvantage of there possibly being a conflict between sets of libraries requested by two or more objects/libraries.
On Linux, compiler drivers (ifort, gfortran, etc.) invisibly add the desired libraries to the command spawned to do the link.
Thanks @sblionel. It looks like we managed to fix the first problem, LFortran can now link on Windows using the MSVC’s link tool, and it links properly, including the LFortran’s runtime library. Thanks for the dumpbin tip. I’ll play with it to get a better understanding. Yes on Linux and macOS things work fine.
Regarding cmake — it seems CMake has some issues recognizing LFortran, the error comes from the internals of CMake and I don’t have any instructions to try, as I already tried the obvious workarounds. I’ll try to ask at some cmake forums, maybe somebody can help there.
On Windows, since you’re currently using MSVC tool sets, can you consider NMAKE? NMAKE is a simpler make utility that works reasonably well with Microsoft toolchain and it can get you going with ironing out LFortran dependencies on the Windows OS until you have fpm working to your satisfaction with LFortran:
To clarify, the issue isn’t getting CMake to work in building LFortran on Windows, rather it’s getting CMake to work properly with LFortran as the chosen compiler for a user’s project. So while we could advise people, “just use nmake”, it’s probably best if we can get this resolved so that someone can download an existing CMake fortran project, and compile it with LFortran.
As an aside, I was under the impression that CMake generated platform-specific makefiles (though I’m not a CMake expert by any stretch of the imagination - my experience with CMake has been uniformly unsavoury). On windows, shouldn’t that be an nmake file? My experience using CMake on Linux and FreeBSD has been that the workflow is: invoke CMake, which generates a makefile → invoke make to build the executable.
CMake creates very specific makefiles (down to the exact location of the various programs that are required to build the program, like your compiler and linker), but it does so based on fairly generic configuration files. My experience with CMake is not as bad as some people’s, but then I have most often been a user of CMake-based projects and I have tried to develop with other build systems, which was not a pleasant experience either .
Crucial here is that CMake understands the LFortran compiler - you need a configuration file that allows it to generate the right commands.
On Linux and macOS, this is how CMake recognizes LFortran:
-- The C compiler identification is AppleClang 12.0.0.12000032
-- The Fortran compiler identification is unknown
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Cray Programming Environment (unknown version) Fortran
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /Users/certik/bin/lfortran - skipped
-- Checking whether /Users/certik/bin/lfortran supports Fortran 90
-- Checking whether /Users/certik/bin/lfortran supports Fortran 90 - yes
It thinks it is a Cray compiler. But it works, since LFortran uses the usual command line options. I guess on Windows it fails somehow.
My plan is to first fix LFortran to work well with fpm, including Windows. Once a few examples work reasonably well, I’ll make a release and ask for help again.
My understanding is that these generators are for generating the makefiles. We do not need to touch them. We need CMake support when it looks for a Fortran compiler.
That will be the next step after I am reasonably sure that thing work and compile using fpm on Windows (and other platforms). Then I would know the bug is most probably in CMake, and I’ll make a Conda release so that people can test it easily without having to compile from git.
Indeed, the first step is to ensure that CMake acknowledges the lfortran compiler.
I will try and see how I can persuade gcc (or cl) to link to the lfortran library. The failure means that CMake cannot accept the lfortran compiler as something useable.
That is presenting a slight problem: I tried to use a plain WIndows command window, but the build procedure requires running a few shell scripts ;). I wil ltry it with MinGW instead (MinGW-w64/MSYS2 to be precise)
Yes, one has to install them using Conda: Installation - LFortran Documentation. I’ll ping you in a few days when we make a release, that way you can just install LFortran itself using Conda.
Good, an alternative would of course be to install the missing utilities and build from source.
(Slightly off topic:
By the way, something very odd has happened: lfortran is no longer recognised as a command or program when I activate the lf environment, even though the PATH variable shows the directory where the program resides. If I type the full path and name, it does work. Before there was no such problem)
Weird. I assume you tried a new terminal and loading the environment again.
I am considering eventually buying a Windows machine and try to develop LFortran there for a while, to get a feel for these things and to ensure everything just works. Until then, I can only make sure it works at the Windows CI, which it does.
.
But it works, since LFortran uses the usual command line options. I guess on Windows it fails somehow.