Infinite configure run after executing make


I’m having a recurrent problem when I try to build ABINIT (it appears regardless the different version I’m building, ranging from v8.8 to the last one in the trunk/develop branch) in our local cluster.

For instance, if I clone my develop branch (which used to compile correctly few months ago) and I execute:


./configure --with-config-file=/home/mroyo/.abinit/build/


The first two commands seem to go fine. However “make” never starts the compilation, it instead runs the configure again and, what is worse, it enters an infinite loop in which it repeats the configure run again and again. The same happens if I try to run a “make clean” or a “make distclean”.

The only suspicious log messages that I can see are these ones:

./config.status: line 2290: /config/scripts/make-optim-dumper: No such file or directory

config.status: executing script-perms commands

config.status: executing source-split commands

config.status: executing long-lines commands

/bin/sh: /config/scripts/shrink-src-files: No such file or directory

CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/mroyo/Flexoelectrics/Src/abinit-develop-last/config/gnu/missing aclocal-1.13 -I config/m4

cd . && /bin/sh /home/mroyo/Flexoelectrics/Src/abinit-develop-last/config/gnu/missing automake-1.13 --gnu

CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/mroyo/Flexoelectrics/Src/abinit-develop-last/config/gnu/missing autoconf

/bin/sh ./config.status --recheck

running CONFIG_SHELL=/bin/sh /bin/sh ./configure --with-config-file=/home/mroyo/.abinit/build/ --no-create --no-recursion

Can anyone help me with this issue?

Hello mroyo! Could you please provide the ac9 file you are using and the complete log from both the configure and the make file?

Also when you say that you can’t compile any versions ranging from v8.8 to trunk/develop: do you always encounter the same problem? I believe that the build system have undergo a big change when going from v8 to v9. Thus your problem might be external to the build system itself?


YEs, it is important for us to have a look at your config.log. From the error messages you show above, I see that some variables usually detected by the configure script are not properly set or do not exist.


Yes the problem is always the same despite I use different configure flags or .ac files for v8 an v9 versions. I agree that the build system must be OK and here I face a problem with our local configuration. Actually, I can compile these versions of the software in other machines.

I’m trying to upload or paste the .ac and config.log in this message but I can’t because I overpass the characters limit for a new user. Is there any other way to do this?

Thanks for your help.

You can upload files I believe. Just press the image button when replying to this thread :slight_smile:

I tried but…

Sorry, new users can not upload attachments.

Sorry, new users can not upload attachments.

Can you try again?

Ok, I have been updated to moderator. Thanks!

Let’s see. Here it goes the config.log:
config.log (305.6 KB)

And here the ac9 file with a .log extension (otherwise it complains): (38.2 KB)

Now it’s possible to upload files with extension ac or ac9

1 Like

So, do you have any idea of what is going on?

Hi Miquel,

Can you send me the “Final remarks” at the end of ./configure ?


Hi Jean-Michel,

here you have it:

=== Final remarks ===

Core build parameters

  • C compiler : gnu version 10.2

  • Fortran compiler : gnu version 10.2

  • architecture : intel xeon (64 bits)

  • debugging : basic

  • optimizations : standard

  • OpenMP enabled : no (collapse: ignored)

  • MPI enabled : yes (flavor: auto)

  • MPI in-place : no

  • MPI-IO enabled : yes

  • GPU enabled : no (flavor: none)

  • LibXML2 enabled : no

  • LibPSML enabled : no

  • XMLF90 enabled : no

  • HDF5 enabled : yes (MPI support: yes)

  • NetCDF enabled : yes (MPI support: yes)

  • NetCDF-F enabled : yes (MPI support: yes)

  • FFT flavor : dfti (libs: user-defined)

  • LINALG flavor : mkl (libs: user-defined)

  • SCALAPACK enabled : yes

  • ELPA enabled : no

  • FCFLAGS : --free-line-length-none -fallow-argument-mismatch -I/share/apps/easybuild/software/netCDF/4.7.4-gompi-2020b/include -I/share/apps/easybuild/software/netCDF-Fortran/4.5.3-gompi-2020b/include

  • CPATH : /share/apps/easybuild/software/netCDF-Fortran/4.5.3-gompi-2020b/include:/share/apps/easybuild/software/netCDF/4.7.4-gompi-2020b/include:/share/apps/easybuild/software/cURL/7.72.0-GCCcore-10.2.0/include:/share/apps/easybuild/software/HDF5/1.10.7-gompi-2020b/include:/share/apps/easybuild/software/Szip/2.1.1-GCCcore-10.2.0/include:/share/apps/easybuild/software/libxc/4.3.4-GCC-10.2.0/include:/share/apps/easybuild/software/imkl/2020.4.304-gompi-2020b/mkl/include/fftw:/share/apps/easybuild/software/imkl/2020.4.304-gompi-2020b/mkl/include:/share/apps/easybuild/software/OpenMPI/4.0.5-GCC-10.2.0/include:/share/apps/easybuild/software/PMIx/3.1.5-GCCcore-10.2.0/include:/share/apps/easybuild/software/libfabric/1.11.0-GCCcore-10.2.0/include:/share/apps/easybuild/software/UCX/1.9.0-GCCcore-10.2.0/include:/share/apps/easybuild/software/libevent/2.1.12-GCCcore-10.2.0/include:/share/apps/easybuild/software/hwloc/2.2.0-GCCcore-10.2.0/include:/share/apps/easybuild/software/libpciaccess/0.16-GCCcore-10.2.0/include:/share/apps/easybuild/software/libxml2/2.9.10-GCCcore-10.2.0/include/libxml2:/share/apps/easybuild/software/libxml2/2.9.10-GCCcore-10.2.0/include:/share/apps/easybuild/software/XZ/5.2.5-GCCcore-10.2.0/include:/share/apps/easybuild/software/numactl/2.0.13-GCCcore-10.2.0/include:/share/apps/easybuild/software/binutils/2.35-GCCcore-10.2.0/include:/share/apps/easybuild/software/zlib/1.2.11-GCCcore-10.2.0/include

  • Build workflow : monolith

0 deprecated options have been used:.

Configuration complete.
You may now type “make” to build Abinit.
(or “make -j”, where is the number of available processors)

I’ve found some comments about a similar problem in the past and it was due to the Python interpreter not found properly. There are 2 workarounds:

  • Set the PYTHON environment variable to the full path of a Python 3 interpreter;
  • Install the python-is-python3 package on Debian-based distributions.

Be careful that the second suggestion may interfere with external legacy scripts depending on Python 2, if you still rely on outdated implementations for other projects than ABINIT. This should not be a problem for most people, though.

Hello @pouillon

do you think it suffices to create an alias for python pointing to python3? I have tried this option and the problem persists.

Installing the python-is-python3 package does a little bit more than that, thus I don’t know if an alias will solve everything. If you do that, you should also alias python3-config.

Thinking again about this topic, there is a third alternative, which consists in configuring ABINIT in an activated Python virtual environment. Depending on your distribution, you may have to install the python3-venv package first.


/usr/bin/python3 -m venv ~/my-envs/abinit
source ~/my-envs/abinit/bin/activate
../configure ...

Thanks for the suggestion. I have activated the virtual environment as :

but even then, the problem persists )-:

Do you know if it might be a question of using an old version of “make”? I have noticed that the one in the cluster is v3.82, whereas the one in my PC (wherein I can build abinit with no problems) is v4.2.1.

Actually, I have realized that the configure detects python3.6 but not python3.6-config:

checking for python3.6… python3.6
checking for python3.6-config… no
checking for python3.7-config… no
checking for python3.6-config… no
checking for python3.5-config… no
checking for python3.4-config… no
checking for python3-config… no
checking for python2.7-config… python2.7-config

So that maybe it is still a question of setting the python3 environment properly.

What happens if you do this?

sudo apt install python3-dev