Linking errors with ET_2020_05 with ETK built ExternalLibraries

Issue #2464 resolved
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 scripts for both libs copies the static library to LAPACK_DIR and BLAS_DIR respectively. For instance:

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

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:

BLAS_DIR      = /<directory_tree to FreeTHC>/FreeTHC2020/Cactus/configs/thc_intel/scratch/external/BLAS
BLAS_LIB_DIRS = /<directory_tree to FreeTHC>/FreeTHC2020/Cactus/configs/thc_intel/scratch/external/BLAS/lib
BLAS_LIBS     = blas


BLAS_DIR      = /<directory_tree to FreeTHC>/FreeTHC2020/Cactus/configs/thc_intel/scratch/external/BLAS
BLAS_LIB_DIRS = /<directory_tree to FreeTHC>/FreeTHC2020/Cactus/configs/thc_intel/scratch/external/BLAS
BLAS_LIBS     = blas

Comments (11)

  1. Roland Haas

    As far as I can tell this bug has been introduced in git hash 22ffa3c "BLAS: use 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.

    @{5b59c8ffe288ee2d9b4ba7ba} would you mind double checking which version of say BLAS you are using, please?


    cd arrangements/ExternalLibraries/BLAS
    svn status -v

    which should return 664 663 rhaas for ET_2020_05. Or:

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

    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. tootle reporter

    @Roland Haas

    @Roland Haas

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

    svn status -v
      M              665      665 roland.haas

    I have made a modification to the 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 ET_RELEASE = ET_2020_05
    Additional Cactus thorns
    !TARGET   = $ARR
    !TYPE     = svn
    !URL      =$1-$2.git/trunk
    !CHECKOUT = ExternalLibraries/OpenBLAS ExternalLibraries/OpenCL ExternalLibraries/pciutils ExternalLibraries/PETSc
    #DISABLED ExternalLibraries/OpenBLAS
    #DISABLED ExternalLibraries/OpenCL
    #DISABLED ExternalLibraries/pciutils
    #DISABLED ExternalLibraries/PETSc

  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$1-$2.git/trunk which is “trunk”. The release branch would read$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. 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