Package: liblapackpp-dev
Version: 2024.10.26-1
Dear Maintainer,
liblapackpp-dev ships only a static liblapackpp.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 lapack_plugin.cc
#include <lapack.hh>
int64_t lu (double* A, int64_t* ipiv)
{ return lapack::getrf( 2, 2, A, 2, ipiv ); }
$ g++ -shared -fPIC lapack_plugin.cc -o libl.so -llapackpp -lblaspp
-llapack -lblas
/usr/bin/x86_64-linux-gnu-ld.bfd:
/usr/lib/gcc/x86_64-linux-gnu/16/../../../x86_64-linux-gnu/liblapackpp.a(getrf.cc.o):
warning: relocation against `_ZTIN6lapack5ErrorE' in read-only section
`.text._ZN6lapack8internal8throw_ifEbPKcS2_S2_z[_ZN6lapack8internal8throw_ifEbPKcS2_S2_z]'
/usr/bin/x86_64-linux-gnu-ld.bfd:
/usr/lib/gcc/x86_64-linux-gnu/16/../../../x86_64-linux-gnu/liblapackpp.a(getrf.cc.o):
relocation R_X86_64_PC32 against symbol
`_ZTISt20bad_array_new_length@@CXXABI_1.3.8'
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: ship also the shared library, which is the upstream
default (upstream sets SOVERSION, i.e. liblapackpp.so.1 for
2024.10.26). I saw Debian policy 10.2 discourages -fPIC in static
archives, so this seems cleaner than building the static library
with CMAKE_POSITION_INDEPENDENT_CODE=ON.
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
libblaspp-dev has the same problem, and I am reporting it separately.
Thanks,
Axel Huebl
