OpenBLAS: `SYMBOLSUFFIX` doesn't seems to work in CMAKE build system

I’m trying to build openblas 0.3.23 (64-bit integer) and use it as blas/lapack for numpy in my WSL. Since numpy’s docs suggests building openblas with 64_ symbol suffix (https://numpy.org/devdocs/user/building.html#bit-blas-and-lapack), so I tried below make cmd:

FC=gfortran USE_THREAD=1 USE_TLS=1 NUM_THREADS=64 DYNAMIC_ARCH=0 \
NO_STATIC=1 INTERFACE64=1 BINARY64=1 \
SYMBOLSUFFIX=64_ make shared

It works well and I can see symbols with 64_ suffix in the shared library:

00000000009593d0 T zunmrz_64_
0000000000959dc0 T zunmtr_64_
000000000095a540 T zupgtr_64_
000000000095a980 T zupmtr_64_

However, when I tried to switch to cmake system:

 cmake -B build64 -S OpenBLAS-0.3.23 \
    -DBUILD_SHARED_LIBS=ON \
    -DBUILD_WITHOUT_LAPACK=OFF \
    -DBUILD_WITHOUT_CBLAS=OFF \
    -DBUILD_TESTING=OFF \
    -DNO_AFFINITY=ON \
    -DUSE_THREAD=1 \
    -DUSE_TLS=1 \
    -DNO_WARMUP=1 \
    -DNUM_THREADS=64 \
    -DDYNAMIC_ARCH=OFF \
    -DINTERFACE64=1 \
    -DBINARY64=1 \
    -DSYMBOLSUFFIX=64_

It builds fine, but the shared library generated doesn’t has 64_ symbol suffix:

0000000000953c70 T zunmrz_
00000000009545f0 T zunmtr_
0000000000954d30 T zupgtr_
0000000000955150 T zupmtr_

I noticed that the exports/gensymbol cmd, which seems used to rename symbols, gives some error messages, though it doesn’t stop the cmake building process:

xxx/exports/gensymbol objcopy x86_64 _ 0 0 0 0 0 0 "" "64_" 0 false ON ON ON ON > xxx/build64/objcopy.def

I believe the exports/gensymbol is a bash script that expects 0/1 as boolean inputs and the cmake false/ON is unknown to it, so we need to convert itto 0/1 first:

--- CMakeLists.txt.1    2023-04-09 00:57:02.275990909 -0700
+++ CMakeLists.txt      2023-04-08 19:27:39.000000000 -0700
@@ -400,7 +400,7 @@

   if (NOT USE_PERL)
   add_custom_command(TARGET ${OpenBLAS_LIBNAME}_shared POST_BUILD
-    COMMAND  ${PROJECT_SOURCE_DIR}/exports/gensymbol "objcopy" "${ARCH}" "${BU}" "${EXPRECISION_IN}" "${NO_CBLAS_IN}" "${NO_LAPACK_IN}" "${NO_LAPACKE_IN}" "${NEED2UNDERSCORES_IN}" "${ONLY_CBLAS_IN}" \"${SYMBOLPREFIX}\" \"${SYMBOLSUFFIX}\" "${BUILD_LAPACK_DEPRECATED}" "${BUILD_BFLOAT16}" "${BUILD_SINGLE}" "${BUILD_DOUBLE}" "${BUILD_COMPLEX}" "${BUILD_COMPLEX16}" > ${PROJECT_BINARY_DIR}/objcopy.def
+    COMMAND  ${PROJECT_SOURCE_DIR}/exports/gensymbol "objcopy" "${ARCH}" "${BU}" "${EXPRECISION_IN}" "${NO_CBLAS_IN}" "${NO_LAPACK_IN}" "${NO_LAPACKE_IN}" "${NEED2UNDERSCORES_IN}" "${ONLY_CBLAS_IN}" \"${SYMBOLPREFIX}\" \"${SYMBOLSUFFIX}\" "$<BOOL:${BUILD_LAPACK_DEPRECATED}>" "$<BOOL:${BUILD_BFLOAT16}>" "$<BOOL:${BUILD_SINGLE}>" "$<BOOL:${BUILD_DOUBLE}>" "$<BOOL:${BUILD_COMPLEX}>" "$<BOOL:${BUILD_COMPLEX16}>" > ${PROJECT_BINARY_DIR}/objcopy.def
     COMMAND objcopy -v --redefine-syms ${PROJECT_BINARY_DIR}/objcopy.def  ${PROJECT_BINARY_DIR}/lib/lib${OpenBLAS_LIBNAME}.so
     COMMENT "renaming symbols"
     )

However, even after this patch, I’m still unable to see 64_ symbol suffix though the exports/gensymbol command doesn’t complain anything.

I’m using cmake 3.26.3 with gcc/gfortan: 12.2.1 20230211 (arch linux) and below are outputs from the cmake:

-- Using 64-bit integers.
-- GEMM multithread threshold set to 4.
-- Multi-threading enabled with 64 threads.
-- Running getarch
-- GETARCH results:
CORE=ZEN
LIBCORE=zen
NUM_CORES=16
HAVE_MMX=1
HAVE_SSE=1
HAVE_SSE2=1
HAVE_SSE3=1
HAVE_SSSE3=1
HAVE_SSE4_1=1
HAVE_SSE4_2=1
HAVE_SSE4A=1
HAVE_AVX=1
HAVE_AVX2=1
HAVE_FMA3=1
MAKE += -j 16
...
-- fortran lapack
-- Building Single Precision
-- Building Double Precision
-- Building Single Precision Complex
-- Building Double Precision Complex
-- adding suffix 64_ to names of exported symbols in openblas_64
-- Generating openblas_config.h in include/openblas64
-- Generating f77blas.h in include/openblas64
-- Generating cblas.h in include/openblas64
-- Copying LAPACKE header files to include/openblas64

Let me know if you need more info to reproduce this issue.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 16 (8 by maintainers)

Most upvoted comments

I had started to decorate them too but then the question came up if going for visibility “hidden” would be a better choice. Need to resume that work