Linking errors with ET_2020_05 with ETK built ExternalLibraries

Create issue
Issue #2464 resolved
Samuel Tootle created an issue

When compiling ET_2020_05, I obtained linking errors against LAPACK and BLAS even though these were set to BUILD in the optionslist.

After further review, the issue turned out to be that bindings/Configuration/Capabilities/make.BLAS.defn and make.LAPACK.defn both had the libraries listed in LAPACK_DIR/lib and BLAS_DIR/lib respectively, however, the configure.sh scripts for both libs copies the static library to LAPACK_DIR and BLAS_DIR respectively. For instance:
ExternalLibraries/LAPACK/configure.sh

        echo "LAPACK: Installing..."
        cp liblapack.a ${LAPACK_DIR}
        popd

Changing the LAPACK_LIB_DIRS and BLAS_LIB_DIRS to the base directory where the library is located results in correct linking.

For instance, Old make.BLAS.defn:

INC_DIRS +=  $(BLAS_INC_DIRS)
INC_DIRS_F +=  $(BLAS_INC_DIRS)
BLAS_DIR      = /<directory_tree to FreeTHC>/FreeTHC2020/Cactus/configs/thc_intel/scratch/external/BLAS
BLAS_INC_DIRS =
BLAS_LIB_DIRS = /<directory_tree to FreeTHC>/FreeTHC2020/Cactus/configs/thc_intel/scratch/external/BLAS/lib
BLAS_LIBS     = blas
HAVE_CAPABILITY_BLAS = 1

New:

NC_DIRS +=  $(BLAS_INC_DIRS)
INC_DIRS_F +=  $(BLAS_INC_DIRS)
BLAS_DIR      = /<directory_tree to FreeTHC>/FreeTHC2020/Cactus/configs/thc_intel/scratch/external/BLAS
BLAS_INC_DIRS =
BLAS_LIB_DIRS = /<directory_tree to FreeTHC>/FreeTHC2020/Cactus/configs/thc_intel/scratch/external/BLAS
BLAS_LIBS     = blas
HAVE_CAPABILITY_BLAS = 1

Comments (11)

  1. Roland Haas

    As far as I can tell this bug has been introduced in git hash 22ffa3c "BLAS: use bash_utils.sh to search for library" of ExternalLibraries-BLAS which is however only in master, not in ET_2020_05. It will still need to be fixed obviously.

    @Samuel Tootle would you mind double checking which version of say BLAS you are using, please?

    Either:

    cd arrangements/ExternalLibraries/BLAS
    svn status -v configure.sh
    

    which should return 664 663 rhaas configure.sh for ET_2020_05. Or:

    cd arrangements/ExternalLibraries/BLAS
    git log -1 --pretty=oneline configure.sh
    

    which should return aa1b84cbc1509ede92e5e42d0e37943232777b43 (HEAD -> ET_2020_05, tag: ET_2020_05_v0, tag: ET_2019_10_v0, tag: ET_2019_03_v0, tag: Cactus_4.7.0_v0, tag: Cactus_4.6.0_v0, origin/ET_2020_05) BLAS: correct name of tarball file used when checking deps,

  2. Samuel Tootle reporter

    @Roland Haas

    @Roland Haas

    would you mind double checking which version of say BLAS you are using, please?

    svn status -v configure.sh
      M              665      665 roland.haas  configure.sh
    

    I have made a modification to the configure.sh script for BLAS and LAPACK to put the static library in the correct location in the interim so that when I recompile I don’t have the same issue again. I checked the other .git/config in repos and confirmed that I have branch ET_2020_05 checked out. Here is the ExternalLibraries section of my thornlist:

    !DEFINE ROOT = Cactus
    !DEFINE ARR  = $ROOT/arrangements
    !DEFINE COMPONENTLIST_TARGET = $ROOT/thornlists/
    
    !DEFINE ET_RELEASE = ET_2020_05
    ####
    Additional Cactus thorns
    !TARGET   = $ARR
    !TYPE     = svn
    !URL      = https://github.com/EinsteinToolkit/$1-$2.git/trunk
    !CHECKOUT = ExternalLibraries/OpenBLAS ExternalLibraries/OpenCL ExternalLibraries/pciutils ExternalLibraries/PETSc
    ExternalLibraries/BLAS
    ExternalLibraries/FFTW3
    ExternalLibraries/GSL
    ExternalLibraries/HDF5
    ExternalLibraries/hwloc
    ExternalLibraries/LAPACK
    ExternalLibraries/libjpeg
    ExternalLibraries/LORENE
    ExternalLibraries/MPI
    #DISABLED ExternalLibraries/OpenBLAS
    #DISABLED ExternalLibraries/OpenCL
    ExternalLibraries/OpenSSL
    #ExternalLibraries/PAPI
    #DISABLED ExternalLibraries/pciutils
    #DISABLED ExternalLibraries/PETSc
    ExternalLibraries/pthreads
    ExternalLibraries/zlib
    

  3. Roland Haas

    Thank you for the quick response.
    This looks like trunk (master) to me. The revision number is 665 while for ET_2020_05 it is 663 and 664 (last revision the file was modified, last revision the repository was modified). The “M” also means that there are local modifications to the file, which could be anything so you may want to check what “svn diff” reports (note in “master” the effect that you describe is definitely there, I am just trying to reconstruct how you ended up with what is apparently “master” when intending to use “ET_2020_05”). In your thornlist you have https://github.com/EinsteinToolkit/$1-$2.git/trunk which is “trunk”. The release branch would read https://github.com/EinsteinToolkit/$1-$2.git/branches/$ET_RELEASE due to differences in how git and subversion handle master / trunk (the latter not being just another branch to svn but special). Is this an official thornlist that you downloaded from an ET website (if so it needs to be fixed)? One way of ending with a file like yours is to take a development thornlist and change the ET_RELEASE variable from “master” to “ET_2020_05” which is not quite sufficient unfortunately.

  4. Samuel Tootle reporter

    @Roland Haas Thank you for the information related to SVN as that is not a system I’ve used in the past. Your assessment is correct in that I had used a modified thornlist in a clean directory and replaced the ET_RELEASE variable with the latest release before pulling with GetComponents.

    Both pull requests reflect the current fix that I have implemented, so that looks good from my perspective.

  5. Log in to comment