I am able to build a serial version of GULP by the:
./mkgulp
command. This version works OK …
I was trying to build the MPI version of GULP by the command:
./mkgulp -m
At first the building reported missing scalapack - so I had installed scalpack support …
I move forward but I get errors like:
pgfnff_solve.F:(.text+0xb40): undefined reference to `dgemm_’
I believe dgemm is a part of lapack witch is correctly installed (works with serial version).
Ani idea what to check ?
Hi Michal
It’s not enough to install the library on your computer - you also need to add the library name to the link line in mkgulp, usually under the MLIB variable, otherwise the build won’t see it.
Regards,
Julian
I see the identical issue was already discussed in another topic - and the solution was to recompile sclapack, lapack and blass locally. I am not sure how to do this.
What I do not understand:
I believe the lapack and blass are used for the serial version. This compiles OK and the code works OK as well. Why the MPI version on the same system does not compile ? Do the setup differ so much according the library configurations ?
The build was reporting issue with -lscalapack. I had installed scalpack (by the package manager pacman) and this issue had disappeared without mkgulp modification. So is scalpack correctly installed ?
Do I really need to modify the MLIB variable if the libraries are in default directories ?
What should I put in this variable ?
I apology for maybe stupid questions - I have limited experiences with code build under POSIX environment …
I had checked I have all the required librares in the shared /lib directory:
libscalapack.a
libblas.a
libopenblas.a
liblapack.a
This directory is used for other lib used for linking as well …
So what can be wrong ?
I had checked the library directory are correctly included in the link as well:
$ ld --verbose | grep SEARCH_DIR | tr -s ’ ;’ \012
SEARCH_DIR(“=/ucrt64/x86_64-w64-mingw32/lib”)
SEARCH_DIR(“=/ucrt64/lib”)
SEARCH_DIR(“=/usr/local/lib”)
SEARCH_DIR(“=/lib”)
SEARCH_DIR(“=/usr/lib”)
I have them in the /ucrt64/lib …
So what can be wrong ?
After a few hours of work comparing serial and and MPI GULP logs I had found the issue.
Non functional end sequence for linker generated by mkgulp:
-L/opt/homebrew/lib -lscalapack zdotc.o …/…/Utils/pGFNFF/Src//libpGFNFF.a -o gulp
Functional one generated by me:
…/…/Utils/pGFNFF/Src//libpGFNFF.a -lscalapack -llapack -lopenblas -o gulp
So I have all lib OK in correct location, but the mkgulp place them in incorrect order in the link + does not put lapack and openblas in the link (serial version does it OK) …
The link line in mkgulp isn’t generated (as in by cmake etc) - it’s set by the user for their choice of libraries on their specific platform. This is why I said you need to modify the link line to reflect the libraries you are using & then it will work (as you’ve found it does).
I am not an expert on making builds setup, but I have a suggestion …
What abut to expect:
The lib are in the standard sub-directories automaticalay accessible by linker ?
The lib names are the standard most common one ?
It means:
Reject the “-L/opt/homebrew/lib”
Put “-lscalapack -llapack -lblas” before the -o gulp
I believe such a modification of the MPI mkgulp setup will make the MPI build functional out of box for most people. And it will give them a glue where to place the lib name if they will differ (as e.g. openblas instead of blas)
There are examples of different link lines in the mkgulp file already, which is configured for the platforms that are supported. I’d assumed that users would look at the existing variants and see that things like -lscalapack -llapack -lblas are needed even if it might not initially be in the link line for the platform they are using. Ultimately the best thing would be to use cmake, but this is something for the future.
On my system the original version of the line makes for PGFNFF_LIB impossible to find procedures from the LIBS … So modification of the mkgulp is not sufficient for correct build …
In addition after including the -llapac it is required to remove the zdotc.a from the link, otherwise the function is multiple defined in lapack and zdotc.a.
Generally both MPI and serial GULP 6.2.3 built works now perfect (Windows 7-10, msys2 lib, Microsoft MPI).
If there will be any interest for Windows binary distribution from the GULP official side I am ready to supply results of my work.
I understand you are not a Windows fan, but my students have no glue abut Linux (I teach chemists) … It is not my vote - I work under Linux on supercomputers normally …
Hi Michal,
Obviously you should modify the Makefile as necessary to work for your specific system, as well as removing zdotc if it’s provided by another library (as per lapack.o and blas.o which also come with GULP that would duplicate libraries if externally linked). It works fine on Mac and our Linux supercomputers, so it looks like this is a quirk of Windows. We have built Windows serial versions here, but have to do it by performing a platform-independent compilation under Linux.
Best regards,
Julian