Dear Maintainer,

libblaspp-dev ships only a static libblaspp.a. debian/rules builds it
with -DBUILD_SHARED_LIBS=NO, so CMake does not add -fPIC and the objects
are compiled as PIE (the GCC default). As a result the archive cannot be
linked into any shared library, e.g. a Python extension module. Linking
into executables works.

Reproducer (debian:sid amd64 container, g++ 4:16.1.0-3, binutils 2.47-6):

  $ cat blas_plugin.cc
  #include <blas.hh>
  double dot3 (double const* x, double const* y)
  { return blas::dot( 3, x, 1, y, 1 ); }

  $ g++ -shared -fPIC blas_plugin.cc -o libb.so -lblaspp -lblas
  /usr/bin/x86_64-linux-gnu-ld.bfd:
/usr/lib/gcc/x86_64-linux-gnu/16/../../../x86_64-linux-gnu/libblaspp.a(dot.cc.o):
warning: relocation against `_ZTIN4blas5ErrorE' in read-only section
`.text._ZN4blas4impl3dotIdEET_lPKS2_lS4_l[_ZN4blas4impl3dotIdEET_lPKS2_lS4_l]'
  /usr/bin/x86_64-linux-gnu-ld.bfd:
/usr/lib/gcc/x86_64-linux-gnu/16/../../../x86_64-linux-gnu/libblaspp.a(dot.cc.o):
relocation R_X86_64_PC32 against symbol `_ZTVN4blas5ErrorE' can not be used
when making a shared object; recompile with -fPIC
  /usr/bin/x86_64-linux-gnu-ld.bfd: final link failed: bad value
  collect2: error: ld returned 1 exit status

Suggested fix: we could also ship the shared library, which is the
upstream default (upstream sets SOVERSION, i.e. libblaspp.so.2 for
2025.05.28). I saw that the Debian policy 10.2 discourages -fPIC in
static archives, so this seems cleaner than building the static
library with CMAKE_POSITION_INDEPENDENT_CODE=ON.
Note that debian/rules configures twice (override_dh_auto_configure and
override_dh_auto_build), so any flag change is needed in both places.

Real-world impact: the Python bindings of WarpX fail to build against
this package (seen on Ubuntu 26.04, same version):
https://github.com/BLAST-WarpX/warpx/issues/7250

liblapackpp-dev has the same problem, I reported it separately.

Thanks,
Axel Huebl