5

My main problem is getting this error:

Makefile:463: recipe for target 'znep.out' failed

after running make

I was trying to install GPAW (g Projector Augmented Wave method, for DFT simulations) on my machine. ASE is working, and I already installed the Libxc, and compiled the BLAS libraries as specified here but when performing 'make' on the extracted package I always get the same error:

~/Downloads/lapack-3.8.0$ make 

gfortran -O2 -frecursive -c -o zunt03.o zunt03.f
gfortran  -o xeigtstz zchkee.o zbdt01.o zbdt02.o zbdt03.o zbdt05.o zchkbb.o zchkbd.o zchkbk.o zchkbl.o zchkec.o zchkgg.o zchkgk.o zchkgl.o zchkhb.o zchkhs.o zchkst.o zchkst2stg.o zchkhb2stg.o zckcsd.o zckglm.o zckgqr.o zckgsv.o zcklse.o zcsdts.o zdrges.o zdrgev.o zdrges3.o zdrgev3.o zdrgsx.o zdrgvx.o zdrvbd.o zdrves.o zdrvev.o zdrvsg.o zdrvsg2stg.o zdrvst.o zdrvst2stg.o zdrvsx.o zdrvvx.o zerrbd.o zerrec.o zerred.o zerrgg.o zerrhs.o zerrst.o zget02.o zget10.o zget22.o zget23.o zget24.o zget35.o zget36.o zget37.o zget38.o zget51.o zget52.o zget54.o zglmts.o zgqrts.o zgrqts.o zgsvts3.o zhbt21.o zhet21.o zhet22.o zhpt21.o zhst01.o zlarfy.o zlarhs.o zlatm4.o zlctes.o zlctsx.o zlsets.o zsbmv.o zsgt01.o zslect.o zstt21.o zstt22.o zunt01.o zunt03.o dlafts.o dlahd2.o dlasum.o dlatb9.o dstech.o dstect.o dsvdch.o dsvdct.o dsxt1.o alahdg.o alasum.o alasvm.o alareq.o ilaenv.o xerbla.o xlaenv.o chkxer.o ../../libtmglib.a ../../liblapack.a ../../librefblas.a
make[2]: Leaving directory '/home/joshua/Downloads/lapack-3.8.0/TESTING/EIG'
NEP: Testing Nonsymmetric Eigenvalue Problem routines
./EIG/xeigtstz < nep.in > znep.out 2>&1
Makefile:463: recipe for target 'znep.out' failed
make[1]: *** [znep.out] Error 139
make[1]: Leaving directory '/home/joshua/Downloads/lapack-3.8.0/TESTING'
Makefile:42: recipe for target 'lapack_testing' failed
make: *** [lapack_testing] Error 2

I used the default configuration for the 'Makefile' which is proposed in the Installation instructions. The default file is in here.

Any suggestion? I use Kubuntu 17.10

4
  • It looks like it compiled OK but one of the post-compilation tests failed. did you examine the znep.out file? There may be more details near the end of that - hopefully some kind of error message about what the problem is. BTW, gpaw is packaged for ubuntu & kubuntu - why not just run sudo apt-get install gpaw gpaw-data?
    – cas
    Mar 6, 2018 at 1:05
  • 2
    Don't ask me to explain why, but setting ulimit -s unlimited as discussed here Install CLAPACK-3.2.1 in fedora 23 appears to get past this error for me (on Ubuntu 17.10) Mar 6, 2018 at 1:22
  • @steeldriver Would you like to add it as an answer? It really worked, as it states in the answer you provide: Basically, it increases the limits on the scratch space in memory allocated to a thread. Mar 7, 2018 at 3:21
  • 1
    @JoshuaSalazar please go ahead and write an answer yourself - you probably have a better understanding of the solution than me Mar 7, 2018 at 23:49

3 Answers 3

7

After attending to a HPC lecture and doing some research I had the answer.

It looks like the kernel associates a certain amount of memory to the compilation processes. This feature helps in some cases, when bugs can arise and those start to allocate unnecessarily big amounts of memory. But sometimes, the compilation requires more memory than usual and start getting errors.

Then, by using the following command, it sets an unlimited amount of memory to the compilation.

ulimit -s unlimited

Now everything works fine.

Thanks to @steeldriver for the extra questions.

0
0

The ulimit -s unlimited workaround did not completely solve the problem for me. There was an additional failure caused by the gcc stack smashing protector:

# cat TESTING/snep.out 
*** stack smashing detected ***: <unknown> terminated
IOT Trap
 Tests of the Nonsymmetric Eigenvalue Problem routines

To turn off the stack smashing protector, edit the CFLAGS line in make.inc to:

 CFLAGS    = -O3 -I$(TOPDIR)/INCLUDE -fno-stack-protector

Then make clean and make all.

It's very possible that the gcc stack smashing detector is detecting real memory bugs here, some comments in this bug report suggest that some of the tests do have off-by-1 errors when indexing some arrays, so it may be worth trying a later version of lapack which includes the fixes from that bug, and if still not fixed, raise a bug upstream.

(Incidentally, I also hit another build bug: it fails to build with a parallel make, i.e. make -j16 all, but works with the standard single process make all.)

0

I had the same problem. I tried the ulimit -s unlimited workaround, but when test runs, rather than when compiling. And all the tests now passed!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .