<div dir="ltr">Package: liblapackpp-dev<br>Version: 2024.10.26-1<br><br>Dear Maintainer,<br><br>liblapackpp-dev ships only a static liblapackpp.a. debian/rules builds it<br>with -DBUILD_SHARED_LIBS=NO, so CMake does not add -fPIC and the objects<br>are compiled as PIE (the GCC default). As a result the archive cannot be<br>linked into any shared library, e.g. a Python extension module. Linking<br>into executables works.<br><br>Reproducer (debian:sid amd64 container, g++ 4:16.1.0-3, binutils 2.47-6):<br><br>  $ cat lapack_plugin.cc<br>  #include <lapack.hh><br>  int64_t lu (double* A, int64_t* ipiv)<br>  { return lapack::getrf( 2, 2, A, 2, ipiv ); }<br><br>  $ g++ -shared -fPIC lapack_plugin.cc -o libl.so -llapackpp -lblaspp -llapack -lblas<br>  /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]'<br>  /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<br>  /usr/bin/x86_64-linux-gnu-ld.bfd: final link failed: bad value<br>  collect2: error: ld returned 1 exit status<br><br>Suggested fix: ship also the shared library, which is the upstream<br>default (upstream sets SOVERSION, i.e. liblapackpp.so.1 for<br>2024.10.26). I saw Debian policy 10.2 discourages -fPIC in static<br>archives, so this seems cleaner than building the static library<br>with CMAKE_POSITION_INDEPENDENT_CODE=ON.<br><br>Real-world impact: the Python bindings of WarpX fail to build against<br>this package (seen on Ubuntu 26.04, same version):<br><a href="https://github.com/BLAST-WarpX/warpx/issues/7250">https://github.com/BLAST-WarpX/warpx/issues/7250</a><br><br>libblaspp-dev has the same problem, and I am reporting it separately.<br><br>Thanks,<br>Axel Huebl</div>