Open hbjusa opened 4 years ago
hum... what issue?
I'm not saying that the compilation is broken, just that it is maybe not quite what people expect. When I was trying to compile and following instructions or using the scalapack_installer script (on this page http://www.netlib.org/scalapack/, with README here: http://netlib.org/scalapack/scalapack_installer/README), something didn't work as expected, and I traced it back to this line.
If you look at the scalapack_install guide (https://docs.google.com/viewer?url=http%3A%2F%2Fwww.netlib.org%2Fscalapack%2Fscalapack_install.ps) it says:
Define F77, NOOPT, F77FLAGS, CC, CCFLAGS, LOADER, LOADFLAGS, ARCH, ARCHFLAGS, and RANLIB, to refer to the compiler and compiler options, loader and loader options, library archiver and options, and ranlib for your machine. If your machine does not require ranlib set RANLIB = echo.
The scalapack_installer pyton script also uses flags:
--ccflags=[FLAGS] : the flags for the C compiler (default -O3)
and it sets CCFLAGS, not CFLAGS.
All of these instructions say to set CCFLAGS, and that's what the installer sets. Also in the Makefile (SRC/Makefile) it first uses CCFLAGS. However, in the line I indicate, it uses CFLAGS. This caused unexpected results for me and I thought it might also affect others, so perhaps it should be CCFLAGS. Of course if you deliberately want them to be different variables, then there is not an issue.
I am perhaps a bit late on this issue, but since it is still open I thought that it could be useful to mention my experience. I had to compile ScaLAPACK with the -fPIC option and later link it to a shared library used in a larger project. I added the option -fPIC to the variable CCFLAGS from SLmake.inc and proceeded to compile the library with make lib
. However, when I tried to link the resulting ScaLAPACK library, the linker kept throwing error messages of the form
relocation R_X86_64PC32 against symbol zlacpy can not be used when making a shared object; recompile with -fPIC.
I ended up adding the line CFLAGS = $(CCFLAGS)
to the SLmake.inc file and that fixed my problem.
Hello,
I tracked down a compilation issue that was causing unexpected results. In the file SRC/Makefile, I think this line:
$(CC) -c $(CFLAGS) $(CDEFS) $(@:.o=.c) -o $@
should maybe be:
$(CC) -c $(CCFLAGS) $(CDEFS) $(@:.o=.c) -o $@