Yes, that is correct, in Fortran 2/3 is an integer division, so the result is 0.
1 Like
Awesome, I am glad it works now. Yes, the Python issues that you discovered are precisely the reason we switched from Python to C++ as the implementation of LFortran. The issues with Python can be summarized as follows:
- The various Python libraries that Jupyter depends on are not always compatible
- You only find out at runtime, and typically get some obscure error message such as the ones above
- There are multiple mechanisms how to install Python packages, and none has became the clear winner yet, although Conda is pretty close; And if you mix and match these mechanisms, things will fail, as you saw above
C++ is unfortunately also missing a package manager (there are several, and none is a clear winner), but in my experience if it compiles, it almost always works. So at least we donāt have to deal with these runtime issues in C++ (or Fortran). The issue still remains how to make it easy to compile. For now Conda is a nice solution as it is already compiled there, but if you want to build from source, itās not easy. For Fortran I think fpm will fix this. C++ currently doesnāt have a solution like that, but if we can improve fpm to also work for C++, which technically I am pretty sure we can, then Iād be happy to use it for LFortran also.
Thank you very much for your support and help. Iāve been using Fortran as the core of the numerical models that Iām working on for a few years, and I enjoy it. Sadly, I do not have the knowledge to contribute to the improvement and development of LFORTRAN, but if there were anything I could do, I would enjoy it.
I believe that LFORTRAN is a potent language. I did a simple test with a simple loop, both in LFORTRAN and Python, and LFORTRAN showed its speed very well. I am not sure if it is possible, but if users can easily add and use packages just like in Python, I think that would be ideal.
I am familiar with Fortran but not with systems programming or conda. Wanting to try another compiler I tried to follow the Lfortran websiteās instructions but was stymied. The lines beginning with 3 or 4 digit numbers are from my history file, showing what I did in my Ubuntu 22.04 system, followed by the error messages and what I tried next. What should I do now?
990 29/03 20:11 conda create -n lf
991 29/03 20:11 locate miniconda
992 29/03 20:14 wget --no-check-certificate https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh -O miniconda.sh
993 29/03 20:14 bash miniconda.sh -b -p $HOME/conda_root
994 29/03 20:15 export PATH="$HOME/conda_root/bin:$PATH"
995 29/03 20:15 conda create -n lf -c conda-forge llvmdev=11.0.1 bison=3.4 re2c python cmake make toml
996 29/03 20:16 conda activate lf
997 29/03 20:16 conda init
998 29/03 20:16 conda activate lf
999 29/03 20:17 h
1000 29/03 20:17 conda activate lf
1001 29/03 20:17 git clone https://github.com/lfortran/lfortran.git
1002 29/03 20:18 cd lfortran
1003 29/03 20:18 ./build0.sh
1004 29/03 20:19 cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_LLVM=yes -DCMAKE_INSTALL_PREFIX=`pwd`/inst .
1005 29/03 20:19 h
1006 29/03 20:20 cmake -DWITH_LLVM=yes -DCMAKE_INSTALL_PREFIX=`pwd`/inst .
1007 29/03 20:20 make -j8
1004 gave this error message
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc - broken
Make Error at /home/john/conda_root/envs/lf/share/cmake-3.29/Modules/CMakeTestCCompiler.cmake:67 (message):
The C compiler
"/usr/bin/cc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: '/home/john/lfortran/CMakeFiles/CMakeScratch/TryCompile-B1lpDx'
Run Build Command(s): /home/john/conda_root/envs/lf/bin/cmake -E env VERBOSE=1 /usr/bin/gmake -f Makefile cmTC_fa862/fast
/usr/bin/gmake -f CMakeFiles/cmTC_fa862.dir/build.make CMakeFiles/cmTC_fa862.dir/build
gmake[1]: Entering directory '/home/john/lfortran/CMakeFiles/CMakeScratch/TryCompile-B1lpDx'
Building C object CMakeFiles/cmTC_fa862.dir/testCCompiler.c.o
/usr/bin/cc -o CMakeFiles/cmTC_fa862.dir/testCCompiler.c.o -c /home/john/lfortran/CMakeFiles/CMakeScratch/TryCompile-B1lpDx/testCCompiler.c
cc: fatal error: cannot execute ācc1ā: execvp: No such file or directory
compilation terminated.
gmake[1]: *** [CMakeFiles/cmTC_fa862.dir/build.make:78: CMakeFiles/cmTC_fa862.dir/testCCompiler.c.o] Error 1
gmake[1]: Leaving directory '/home/john/lfortran/CMakeFiles/CMakeScratch/TryCompile-B1lpDx'
gmake: *** [Makefile:127: cmTC_fa862/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:17 (project)
-- Configuring incomplete, errors occurred!
On trying to see why I got
-- The C compiler identification is unknown
I looked for it and got this:
(lf) john@johns-laptop:/usr/bin$ ls -ltra cc
lrwxrwxrwx 1 root root 20 Dec 25 2018 cc -> /etc/alternatives/cc
(lf) john@johns-laptop:/usr/bin$ ls -ltra /etc/alternatives/cc
lrwxrwxrwx 1 root root 12 Dec 25 2018 /etc/alternatives/cc -> /usr/bin/gcc
(lf) john@johns-laptop:/usr/bin$ ls -ltra /usr/bin/gcc
lrwxrwxrwx 1 root root 6 Aug 5 2021 /usr/bin/gcc -> gcc-11
(lf) john@johns-laptop:/usr/bin$ ls -ltra /usr/bin/gcc-1?
lrwxrwxrwx 1 root root 23 May 1 2022 /usr/bin/gcc-11 -> x86_64-linux-gnu-gcc-11
lrwxrwxrwx 1 root root 23 May 13 2022 /usr/bin/gcc-12 -> x86_64-linux-gnu-gcc-12
lrwxrwxrwx 1 root root 23 Jul 19 2022 /usr/bin/gcc-10 -> x86_64-linux-gnu-gcc-10
lrwxrwxrwx 1 root root 23 Jul 11 2023 /usr/bin/gcc-13 -> x86_64-linux-gnu-gcc-13
(lf) john@johns-laptop:/usr/bin$ ls -ltra x86_64-linux-gnu-gcc-1?
-rwxr-xr-x 1 root root 862976 May 1 2022 x86_64-linux-gnu-gcc-11
-rwxr-xr-x 1 root root 1313952 May 13 2022 x86_64-linux-gnu-gcc-12
-rwxr-xr-x 1 root root 826088 Jul 19 2022 x86_64-linux-gnu-gcc-10
-rwxr-xr-x 1 root root 1018800 Jul 11 2023 x86_64-linux-gnu-gcc-13
(lf) john@johns-laptop:/usr/bin$
@Harper, it looks like your C compiler failed with:
cc: fatal error: cannot execute ācc1ā: execvp: No such file or directory
You are compiling LFortran from source code, which is only needed if you want to help develop it. If you want to use it as a user, then I recommend to install it using conda itself:
conda create -n lf2 -c conda-forge lfortran
conda activate lf2
Thank you @certik. My hello.f90 program worked as expected but then I tried another one which lfortran complained had a syntax error. I reported that as suggested.
But now I find on opening another window in my Ubuntu Linux system that there is no file or directory called lf2 and the lfortran command gave this response:
(base) john:~$ lfortran hello.f90
Command 'lfortran' not found, did you mean:
command 'gfortran' from deb gfortran (4:11.2.0-1ubuntu1)
Try: sudo apt install <deb name>
(base) john:~$
Am I supposed to issue those 2 lines of conda commands every time I open a new window?
(By the way I have no idea why (base) appears in my prompt: I started getting it a few days ago without me telling it to, and in the window I issued those conda commands it was replaced by (lf2)
1 Like
Thanks @Harper for trying out! (base) indicates base environment, this happens when you update conda, it automatically activates the base environment upon startup.
To fix the problem you are facing, switch to lf2 ( assuming here you have successfully installed LFortran ) by executing conda activate lf2, [ verify by ( lf2 ) in place of ( base ) ] and then run your command.
1 Like
Thank you @Pranavchiku. If anyone else has had my problem they might like to know that I have now put
conda activate lf2
at the end of my .bashrc file, and it works. I think of it as lfortranās equivalent of Intelās
source /opt/intel/oneapi/setvars.sh
which is also in my .bashrc to allow compilation with ifort and ifx. Using several compilers is good for hunting both my bugs and compilersā bugs.
2 Likes
Absolutely. The more independent compiler toolchains, the better. Ensuring the Fortran code is truly multiplatform, not tied to any one compiler, and hopefully being able to compile years from now.
I have a problem with LFortran installation too.
Following the Installation ā LFortran
I checked the Git prompt and it seems to work:
You are facing the same problem as what you described using fpm and the intel compiler. Because you installed git in your mingw environment, it is not in the Windows path. Thatās what the error message is about.
You can either add the current git installation folder into the PATH variable, or reinstall git using chocolatey or winget for instance. If you do so, do it from the cmd or powershell terminals, not using msys2.
MinGW acts as a subsystem on windows and as such environmental variables from MinGW are not accessible from Windows and vice versa. Itās your responsibility to add the required folders to PATH.
1 Like
If I drop the idea of using windows for Fortran and go back to Linux, would it be easy to use fpm,Lfortran,intel with fpm? Or Linux is supposed to have all these extra terminals there too?
I personally have 0 experience with Linux but considering that most fortraners program on Linux my guess is that itās fairly easy.
As for Windows, the best experience you can get IMHO is intel+visual studio (not vscode). Your difficulties come from the mixed environment MinGW/Windows. There is some manual steps required to make it work that are not always obvious.
Did you consider using this link for Windows?
I was fine using windows cmd for gfortran and intel cmd for intel compiler. The idea of using new compiler LFortran brings another terminal. Same is the case with fpm that comes with another terminal. Now connecting all to check the code with different compilers is so difficult. The new developments are exciting but definitely not easy to follow for a novice Fortran programmer.
No
You can use WSL on Windows, I use it and it works fine.
For pure windows I have moved to relying mostly on PowerShell, it includes git (at least for me with windows11), so no longer need to use different terminals for that. You can use WSL for testing with Linux, but it will not be a replacement for native windows deployment, simply a means to check that your codes are robust across both platforms.
@hkvzjal yes, WSL is not a replacement for native Windows. Itās just that currently the native Windows experience is not as friendly as Linux or macOS, so it might not be a bad idea to start with WSL, and only then try to migrate to native Windows. LFortran itself builds and runs everywhere.
2 Likes