#1148071 liblapackpp-dev: liblapackpp.a is not PIC, cannot be linked into shared libraries

Package:
liblapackpp-dev
Source:
liblapackpp-dev
Description:
C++ API for the Linear Algebra PACKage (development files)
Submitter:
Axel Huebl
Date:
2026-09-25 05:57:02 UTC
Severity:
normal
#1148071#5
Date:
2026-09-16 17:24:46 UTC
From:
To:
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
#1148071#10
Date:
2026-09-17 13:19:03 UTC
From:
To:
Hi,

Well I thought about this when I initially packaged it, but upstream
did seem to have strict library versioning guarantees when I looked at
it, but maybe I was missing something?


Michael
#1148071#15
Date:
2026-09-24 15:56:32 UTC
From:
To:
Do you mean "did" or "did not" have strict library versioning?

LAPACK++ uses calendar versioning for releases, but its ABI version should
be strict semantic versioning. The ABI is 2.0.0 since the last release; see
this commit:

* 298ac33 2025-05-28 01:44 Mark Gates  Update ABI and Changelog

Mark
#1148071#20
Date:
2026-09-25 05:54:15 UTC
From:
To:
Hi Mark,

Yeah, I meant did not, sorry.

Thanks, that great to hear. We will move forward with adding a shared
library then.


Michael