I have a problem with LFortran installation

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


  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.


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.