Build problems -- libxc detection, error message, linker problems

[zerothi]

I have just tried to compile yambo 5.2.4. Here are some observations:

The error message when passing wrong CPP/FPP flags is very confusing,

Makefile:89: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.

I found the solution in #11, which is to provide something that yambo likes. However, couldn't this be checked at configure time instead at compile time?

2. There is a wrong detection of libxc versions:

$ ./configure ... --with-libxc-path=/opt/gnu/12.3.0/libxc/6.1.0
...
checking for libxc... Found external LibXC version=5, (should be 5)

Huh ?
Config log says that everything succeeds, but it actually only checks whether it has some of the same API as in LibXC 5.
Is yambo able to compile+run with libxc6?

3. Problems with linking the a2y programs, the problem was:

	[interfaces/a2y] a2y (link)
a2y linking failed. Check log/compile_a2y.log
make: *** [config/mk/global/actions/compile_interfaces.mk:36: a2y] Error 1

The log says this:

mpifort -m64 -fPIC -O3 -ftree-vectorize -fexpensive-optimizations -funroll-loops -fprefetch-loop-arrays -march=native -fallow-argument-mismatch -fno-second-underscore   -fopenmp  -I/home/software/bash-build/.compile/yambo-5.2.4/include -I/home/software/bash-build/.compile/yambo-5.2.4/include/headers/common -I/home/software/bash-build/.compile/yambo-5.2.4/include/headers/parser -I/home/software/bash-build/.compile/yambo-5.2.4/lib/yambo/Ydriver/include -I/home/software/bash-build/.compile/yambo-5.2.4/include/driver -I/home/software/bash-build/.compile/yambo-5.2.4/include/version -I/home/software/bash-build/.compile/yambo-5.2.4/lib/external/gfortran/mpifort/include/ -I/opt/gnu/12.3.0/netcdf/4.9.2/include -I/opt/gnu/12.3.0/netcdf/4.9.2/include   -I/opt/gnu/12.3.0/hdf5/1.14.0/include -I/opt/gnu/12.3.0/libxc/6.1.0/include -I/opt/gnu/12.3.0/fftw/3.3.10/include   -I/home/software/bash-build/.compile/yambo-5.2.4/lib/yambo/Ydriver/include -I/home/software/bash-build/.compile/yambo-5.2.4/include/driver -I/home/software/bash-build/.compile/yambo-5.2.4/include/version -o a2y driver.o netcdf_data.o a2y.o a2y_db1.o a2y_wf.o a2y_kb_pp.o -L/home/software/bash-build/.compile/yambo-5.2.4/lib -lint_modules -lbz_ops -lstop_and_restart -linterface -lsetup -lio_parallel -lio -lYio -ltiming -lcommon -loutput -lparser -lparallel -llinear_algebra -lmatrices -lmodules -lcommunicate -lallocations -lmemory -ltools -la2y_Ydriver_main -la2y_Ydriver_interface -la2y_Ydriver_options -ldriver   -lqe_pseudo -lmath77 -lslatec -llocal -L/opt/gnu/12.3.0/scalapack/2.2.0/lib -Wl,-rpath,/opt/gnu/12.3.0/scalapack/2.2.0/lib -lscalapack -L/opt/generic/build-tools/1.0/lib -L/opt/generic/gcc/12.3.0/lib -L/opt/generic/gcc/12.3.0/lib64 -L/opt/generic/gcc/12.3.0/lib -L/opt/generic/gcc/12.3.0/lib64 -L/opt/gnu/12.3.0/lapack/3.12.0/lib -L/opt/gnu/12.3.0/blis/1.0/lib -Wl,-rpath,/opt/generic/build-tools/1.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib64 -Wl,-rpath,/opt/generic/gcc/12.3.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib64 -Wl,-rpath,/opt/gnu/12.3.0/lapack/3.12.0/lib -Wl,-rpath,/opt/gnu/12.3.0/blis/1.0/lib -llapack -lblis -L/opt/generic/build-tools/1.0/lib -L/opt/generic/gcc/12.3.0/lib -L/opt/generic/gcc/12.3.0/lib64 -L/opt/generic/gcc/12.3.0/lib -L/opt/generic/gcc/12.3.0/lib64 -L/opt/gnu/12.3.0/lapack/3.12.0/lib -L/opt/gnu/12.3.0/blis/1.0/lib -Wl,-rpath,/opt/generic/build-tools/1.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib64 -Wl,-rpath,/opt/generic/gcc/12.3.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib64 -Wl,-rpath,/opt/gnu/12.3.0/lapack/3.12.0/lib -Wl,-rpath,/opt/gnu/12.3.0/blis/1.0/lib -L/opt/gnu/12.3.0/scalapack/2.2.0/lib -Wl,-rpath,/opt/gnu/12.3.0/scalapack/2.2.0/lib -lscalapack -L/opt/generic/build-tools/1.0/lib -L/opt/generic/gcc/12.3.0/lib -L/opt/generic/gcc/12.3.0/lib64 -L/opt/generic/gcc/12.3.0/lib -L/opt/generic/gcc/12.3.0/lib64 -L/opt/gnu/12.3.0/lapack/3.12.0/lib -L/opt/gnu/12.3.0/blis/1.0/lib -Wl,-rpath,/opt/generic/build-tools/1.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib64 -Wl,-rpath,/opt/generic/gcc/12.3.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib64 -Wl,-rpath,/opt/gnu/12.3.0/lapack/3.12.0/lib -Wl,-rpath,/opt/gnu/12.3.0/blis/1.0/lib -llapack -lblis -L/opt/generic/build-tools/1.0/lib -L/opt/generic/gcc/12.3.0/lib -L/opt/generic/gcc/12.3.0/lib64 -L/opt/generic/gcc/12.3.0/lib -L/opt/generic/gcc/12.3.0/lib64 -L/opt/gnu/12.3.0/lapack/3.12.0/lib -L/opt/gnu/12.3.0/blis/1.0/lib -Wl,-rpath,/opt/generic/build-tools/1.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib64 -Wl,-rpath,/opt/generic/gcc/12.3.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib64 -Wl,-rpath,/opt/gnu/12.3.0/lapack/3.12.0/lib -Wl,-rpath,/opt/gnu/12.3.0/blis/1.0/lib -L/opt/generic/build-tools/1.0/lib -L/opt/generic/gcc/12.3.0/lib -L/opt/generic/gcc/12.3.0/lib64 -L/opt/generic/gcc/12.3.0/lib -L/opt/generic/gcc/12.3.0/lib64 -L/opt/gnu/12.3.0/lapack/3.12.0/lib -L/opt/gnu/12.3.0/blis/1.0/lib -Wl,-rpath,/opt/generic/build-tools/1.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib64 -Wl,-rpath,/opt/generic/gcc/12.3.0/lib -Wl,-rpath,/opt/generic/gcc/12.3.0/lib64 -Wl,-rpath,/opt/gnu/12.3.0/lapack/3.12.0/lib -Wl,-rpath,/opt/gnu/12.3.0/blis/1.0/lib -llapack -lblis -lblas /home/software/bash-build/.compile/yambo-5.2.4/lib/external/gfortran/mpifort/lib/libiotk.a  -L/opt/gnu/12.3.0/netcdf/4.9.2/lib -lnetcdff -L/opt/gnu/12.3.0/netcdf/4.9.2/lib -lnetcdf -L/opt/gnu/12.3.0/hdf5/1.14.0/lib -lhdf5hl_fortran -lhdf5_fortran -lhdf5_hl -lhdf5 -L/opt/gnu/12.3.0/libxc/6.1.0/lib -lxcf90 -lxcf03 -lxc -L/opt/gnu/12.3.0/fftw/3.3.10/lib -lfftw3 -lfftw3_omp   -lm
/opt/generic/build-tools/1.0/bin/ld: /home/software/bash-build/.compile/yambo-5.2.4/lib/libcommunicate.a(com_utilities_netcdf.o): in function `of_netcdf_shadow_real_':
com_utilities_netcdf.f90:(.text+0x687): undefined reference to `io_variable_bulk_'
/opt/generic/build-tools/1.0/bin/ld: com_utilities_netcdf.f90:(.text+0x7b4): undefined reference to `io_variable_bulk_'
/opt/generic/build-tools/1.0/bin/ld: com_utilities_netcdf.f90:(.text+0x912): undefined reference to `def_variable_bulk_'
/opt/generic/build-tools/1.0/bin/ld: com_utilities_netcdf.f90:(.text+0xa84): undefined reference to `def_variable_bulk_'
/opt/generic/build-tools/1.0/bin/ld: /home/software/bash-build/.compile/yambo-5.2.4/lib/libcommunicate.a(com_utilities_netcdf.o): in function `of_netcdf_shadow_char_':
com_utilities_netcdf.f90:(.text+0x1a90): undefined reference to `def_variable_bulk_'
/opt/generic/build-tools/1.0/bin/ld: com_utilities_netcdf.f90:(.text+0x237e): undefined reference to `io_variable_bulk_'

which suggests a wrong ordering of libraries, i.e. the reference exists in libYio.a, but libcommunicate.a is after.
I can trace this to this file: config/mk/local/static_variables.mk where the wrong ordering occurs.
I tried changing the order, but this file seems to be created at every invocation... So I really have a hard time fixing this...

[zerothi]

And, in addition, executing:

make all

and if one of the steps fails, the return value is still a success, i.e. there is no way to detect whether make failed or not!

Changing the break to an explicit exit 1 should do the trick.

[sangallidavide]

Dear @zerothi , thanks for the feedback. I try to address the points you raised one by one.

However, couldn't this be checked at configure time instead at compile time?

Good point. There is a pre-compiler check.
https://github.com/yambo-code/yambo/blob/5.3/config/m4/acx_fpp.m4
Just, it is not enough. I add "a more proper FPP check" on the todo list. Suggestions are welcome.

There is a wrong detection of libxc versions

We coded the interface with libxc 5, then libxc 6 come out and none so far had time to check it they work. Other point on the todo list.

Problems with linking the a2y program.
I can trace this to this file: config/mk/local/static_variables.mk where the wrong ordering occurs.

Ok, I never experienced this. I just tried and I was not able to reproduce the issue

Anyway, the file to change is
config/mk/global/libraries.mk
Let me now if you figure out a solution

Changing the break to an explicit exit 1 should do the trick.

Good suggestion. Coded, it will enter in the future releases.

P.S.: welcome on the list of people complaining about the yambo compilation.
I'm in that list as well, but so far I've not been able to fix it much ...

[zerothi]

Dear @zerothi , thanks for the feedback. I try to address the points you raised one by one.

However, couldn't this be checked at configure time instead at compile time?

Good point. There is a pre-compiler check. https://github.com/yambo-code/yambo/blob/5.3/config/m4/acx_fpp.m4 Just, it is not enough. I add "a more proper FPP check" on the todo list. Suggestions are welcome.

Hmm, I don't really know, because you seem to be using FPP/CPP to create make files... ?

There is a wrong detection of libxc versions

We coded the interface with libxc 5, then libxc 6 come out and none so far had time to check it they work. Other point on the todo list.
Ok!

Problems with linking the a2y program.
I can trace this to this file: config/mk/local/static_variables.mk where the wrong ordering occurs.

Ok, I never experienced this. I just tried and I was not able to reproduce the issue

Anyway, the file to change is config/mk/global/libraries.mk Let me now if you figure out a solution

Just had a look, there the order seems fine, Yio is listed after communicate, so I am not really sure that fixes it, are there codes that re-orders the items?

Changing the break to an explicit exit 1 should do the trick.

Good suggestion. Coded, it will enter in the future releases.

P.S.: welcome on the list of people complaining about the yambo compilation. I'm in that list as well, but so far I've not been able to fix it much ...

Yeah, sorry... ;)
Better with feedback than none, I guess ;)

[sangallidavide]

Hmm, I don't really know, because you seem to be using FPP/CPP to create make files... ?

Yeah ... We have, inside each folder, a .objects file with the list of files to be compiled. These are used to generate the Makefile. However, these files contain ``project dependent pre-compiler flags'' with the list of files to be compile depending on the project.

I've been fighting for 2 years to change this. I got that approved at the last dev-meeting. But it will take some time to be implemented

Just had a look, there the order seems fine, Yio is listed after communicate, so I am not really sure that fixes it, are there codes that re-orders the items?

I do not think so.
The relevant line is

2Y_LIBS_LD    = tools memory allocations communicate modules matrices linear_algebra parallel parser output common timing Yio io $(IO_MODE) \
                setup interface stop_and_restart bz_ops 

You can check the content of log/compile_a2y. This is mine
mpifort.openmpi -O3 -mtune=native -Wall -fcheck=bounds -fopenmp -I/home/sangalli/data/Codes/yambo/yambo-gpl/releases/5.2/include -I/home/sangalli/data/Codes/yambo/yambo-gpl/releases/5.2/include/headers/common -I/home/sangalli/data/Codes/yambo/yambo-gpl/releases/5.2/include/headers/parser -I/home/sangalli/data/Codes/yambo/yambo-gpl/releases/5.2/lib/yambo/Ydriver/include -I/home/sangalli/data/Codes/yambo/yambo-gpl/releases/5.2/include/driver -I/home/sangalli/data/Codes/yambo/yambo-gpl/releases/5.2/include/version -I/data/shared/yambo-libs/default//gfortran/mpifort.openmpi/include/ -I/data/shared/yambo-libs/default//gfortran/mpifort.openmpi/v4/parallel/include -I/data/shared/yambo-libs/default//gfortran/mpifort.openmpi/v4/parallel/include -I/data/shared/yambo-libs/default//gfortran/mpifort.openmpi/single/include -I/data/shared/yambo-libs/default//gfortran/mpifort.openmpi/single/include -I/data/shared/yambo-libs/default//gfortran/mpifort.openmpi/v4/parallel/include -I/data/shared/yambo-libs/default//gfortran/mpifort.openmpi/include -I/data/shared/yambo-libs/default//gfortran/mpifort.openmpi/include/ -I/home/sangalli/data/Codes/yambo/yambo-gpl/releases/5.2/lib/yambo/Ydriver/include -I/home/sangalli/data/Codes/yambo/yambo-gpl/releases/5.2/include/driver -I/home/sangalli/data/Codes/yambo/yambo-gpl/releases/5.2/include/version -o a2y driver.o netcdf_data.o a2y.o a2y_db1.o a2y_wf.o a2y_kb_pp.o -L/home/sangalli/data/Codes/yambo/yambo-gpl/releases/5.2/lib -lint_modules -lbz_ops -lstop_and_restart -linterface -lsetup -lio_parallel -lio -lYio -ltiming -lcommon -loutput -lparser -lparallel -llinear_algebra -lmatrices -lmodules -lcommunicate -lallocations -lmemory -ltools -la2y_Ydriver_main -la2y_Ydriver_interface -la2y_Ydriver_options -ldriver -lqe_pseudo -lmath77 -lslatec -llocal /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/lib/libscalapack.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/lib/libblacs.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/lib/libblacs_C_init.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/lib/libblacs_init.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/lib/liblapack.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/lib/libblas.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/lib/libiotk.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/v4/parallel/lib/libnetcdff.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/v4/parallel/lib/libnetcdf.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/v4/parallel/lib/libhdf5_hl_fortran.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/v4/parallel/lib/libhdf5_fortran.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/v4/parallel/lib/libhdf5_hl.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/v4/parallel/lib/libhdf5.a -lz -lm -ldl /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/lib/libxcf90.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/lib/libxcf03.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/lib/libxc.a /data/shared/yambo-libs/default//gfortran/mpifort.openmpi/lib/libfftw3.a -lm

Yeah, sorry... ;)
Better with feedback than none, I guess ;)

Nothing to sorry about .. I can use this in support to my battle "let's change the compilation scheme" ;-)

[zerothi]

Thanks for sharing, I'll dig a bit further.

I would recommend you go the cmake way, yes, it has many issues. But many projects are moving towards this. And since you are part of MaX, I presume there would be much collaboration you can take, siesta+qe also made the transition. ;)

Sorry for the blurp ;)

[sangallidavide]

Yeah, this is a point we discussed. On the long term our plan is also to switch to cmake.