error in make

[mxzhai-maker]

Error in make for compiling the Openblas library such as follows:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0 0x2B66E2D51697
#1 0x2B66E2D51CDE
#2 0x2B66E35AE27F
#3 0x2B66E2E104C0
#4 0x2B66E2E1DE27
#5 0x403281 in MAIN__ at sblat1.f:?
make: *** [level1] Segmentation fault (core dumped)

CPU ：Intel(R) Xeon(R) CPU E5-2678 v3 @ 2.50GHz

[martin-frbg]

Which version of OpenBLAS is that, and which compiler are you using ? (If gcc+gfortran, please make sure they are both the same version)

[mxzhai-maker]

The version of OpenBLAS is 0.3.10. The version of gcc and gfortran are both 9.1.0. At 2020-08-13 22:13:36, "Martin Kroeker" <[email protected]> wrote: Which version of OpenBLAS is that, and which compiler are you using ? (If gcc+gfortran, please make sure they are both the same version) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[martin-frbg]

Very strange. E5-2678v3 should be standard "Haswell" architecture, I do not see why OpenBLAS should fail in this simple single-precision BLAS test unless there is a problem with your hardware.

[mxzhai-maker]

sorry！Maybe my information is not enough. I found the library path is wrong: ../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../.. -lc gfortran -O2 -Wall -frecursive -fno-optimize-sibling-calls -m64 -mavx2 -o dblat3 dblat3.o ../libopenblas_haswellp-r0.3.10.a -lm -lpthread -lgfortran -lm -lpthread -lgfortran -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../.. -lc gfortran -O2 -Wall -frecursive -fno-optimize-sibling-calls -m64 -mavx2 -o cblat3 cblat3.o ../libopenblas_haswellp-r0.3.10.a -lm -lpthread -lgfortran -lm -lpthread -lgfortran -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../.. -lc gfortran -O2 -Wall -frecursive -fno-optimize-sibling-calls -m64 -mavx2 -o zblat3 zblat3.o ../libopenblas_haswellp-r0.3.10.a -lm -lpthread -lgfortran -lm -lpthread -lgfortran -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../.. -lc OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat1 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x2AB256D97697 #1 0x2AB256D97CDE #2 0x2AB2575F427F #3 0x2AB256E564C0 #4 0x2AB256E63E27 #5 0x403281 in MAIN__ at sblat1.f:? make[1]: *** [level1] Segmentation fault (core dumped) make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/public1/home/sc50250/software/OpenBLAS-0.3.10/test' make: *** [tests] Error 2 I use the gcc 9.1.0, but the libthread and libgfortran path is gcc 4.8.5. I wonder to know how to change the library path. At 2020-08-13 23:29:43, "Martin Kroeker" <[email protected]> wrote: Very strange. E5-2678v3 should be standard "Haswell" architecture, I do not see why OpenBLAS should fail in this simple single-precision BLAS test unless there is a problem with your hardware. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[martin-frbg]

Possibly you still have a link from /usr/bin/cc to the old gcc ? And you should be able to set the library path with `export LD_LIBRARY_PATH= to where your gcc lib (or lib64) directory is.

[mxzhai-maker]

[sc50250@ln22%bscc-a OpenBLAS-0.3.10]$ less Makefile [sc50250@ln22%bscc-a OpenBLAS-0.3.10]$ echo $LD_LIBRARY_PATH /public1/soft/gcc/9.1.0/lib64:/public1/soft/gcc/9.1.0//lib64:/public1/soft/gcc/9.1.0//lib:/public1/soft/gcc/9.1.0//libexec:/public1/home/sc50250/software/lib/openblas/0.3.10_gcc4.8.5/lib:/public1/home/sc50250/software/openmpi_install/lib: The gcc9.1.0 lib directory is already added the DLL. At 2020-08-14 00:02:40, "Martin Kroeker" <[email protected]> wrote: Possibly you still have a link from /usr/bin/cc to the old gcc ? And you should be able to set the library path with `export LD_LIBRARY_PATH= to where your gcc lib (or lib64) directory is. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mxzhai-maker]

The gcc 9.1.0 lib directory exist in the DLL path, but the make command still use the old gcc lib directory. At 2020-08-14 00:02:40, "Martin Kroeker" <[email protected]> wrote: Possibly you still have a link from /usr/bin/cc to the old gcc ? And you should be able to set the library path with `export LD_LIBRARY_PATH= to where your gcc lib (or lib64) directory is. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[martin-frbg]

Hmm. And you did the build with something like make CC=/public1/soft/gcc/9.1.0/bin/gcc FC=/public1/soft/gcc/9.1.0/bin/gfortran ?

[mxzhai-maker]

It is ok! Thanks At 2020-08-14 00:32:14, "Martin Kroeker" <[email protected]> wrote: Hmm. And you did the build with something like make CC=/public1/soft/gcc/9.1.0/bin/gcc FC=/public1/soft/gcc/9.1.0/bin/gfortran ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mxzhai-maker]

It is ok! But i wonder to know what's the difference between the two? At 2020-08-14 00:32:14, "Martin Kroeker" <[email protected]> wrote: Hmm. And you did the build with something like make CC=/public1/soft/gcc/9.1.0/bin/gcc FC=/public1/soft/gcc/9.1.0/bin/gfortran ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[martin-frbg]

Well, you did not write what you did before, so I can only guess. If CC is not set, the c_check script will default to using the "cc" command for figuring out what compiler and libraries to use. If /usr/bin/cc is still linked to the old gcc-4.8.5 that came with the original system installation, this will put the wrong entries in the generated Makefile.conf

[mxzhai-maker]

Ok. Thank you very much! At 2020-08-14 01:03:23, "Martin Kroeker" <[email protected]> wrote: Well, you did not write what you did before, so I can only guess. If CC is not set, the c_check script will default to using the "cc" command for figuring out what compiler and libraries to use. If /usr/bin/cc is still linked to the old gcc-4.8.5 that came with the original system installation, this will put the wrong entries in the generated Makefile.conf — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.