In bug 651997 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651997 libarmadillo2 is listed as version "2.2.5+dfsg-1", which implies that the header files for armadillo have been updated to a later version, but not the run-time library. Otherwise it's impossible to obtain the "undefined symbol: wrapper_dgesv_" error. In turn this suggests a packaging problem.
To fix this issue, just make sure that the system uses the same version of the header files as the version of the run-time library. Specifically, this means if Armadillo 2.4.2 is used, both the headers _and_ the run-time library must be at version 2.4.2. Explanation: Armadillo is made up of two components: (i) template code in headers, (ii) a very thin run-time library that simply pulls in Lapack and Blas. In version 2.2.5, the run-time library was in effect "empty", apart from being linked with Lapack and Blas. It had no functions which were called from the template code. Instead, template code directly called functions present in Lapack and Blas. In effect, -larmadillo was an alias for -llapack -lblas (and Atlas, if it was present). Due to the recent change in the behaviour of the linker in Ubuntu and Debian, the above pulling trick doesn't work anymore. As such, in Armadillo 2.4.2 the run-time library wraps Lapack and Blas functions with simple forwarding functions. The template header code then calls the forwarding functions instead of calling Lapack or Blas directly. In other words: the run-time library in version 2.2.5 doesn't have enough functionality for version 2.4.2 of the headers. The run-time library in version 2.4.2 has "more" functionality than the run-time library in 2.2.5. It has functions such as wrapper_dgesv_(), which simply calls dgesv_(). The run-time library in version 2.2.5 did not have any functionality (ie. no functions) apart from relying on the linking trick. On 21 December 2011 02:12, Kumar Appaiah <aku...@debian.org> wrote: > I am CCing upstream here. > > Dear Conrad, > > Was an shlib bump warranted, based on your view of > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651997 ? > > Thanks. > > Kumar > > On Tue, Dec 20, 2011 at 11:35:53AM +0100, Johannes Ring wrote: >> [Adding Kumar (maintainer of Armadillo) in Cc] >> >> On Tue, Dec 20, 2011 at 10:16 AM, Julien Cristau >> <julien.cris...@logilab.fr> wrote: >> > On Mon, Dec 19, 2011 at 12:46:46 +0100, Johannes Ring wrote: >> >> On Mon, Dec 19, 2011 at 10:37 AM, Andreas Kloeckner <inf...@tiker.net> >> >> wrote: >> >> > This being as it is, could you upload a new package with tightened >> >> > dependencies? >> >> >> >> The dependency on libarmadillo2 is added automatically by >> >> ${shlibs:Depends}. I guess I could add a version requirement for >> >> libarmadillo-dev in Build-Depends, but DOLFIN does not depend on a >> >> specific version of Armadillo, so I don't see why I should. You had >> >> this problem because you were using an old libarmadillo2 (version >> >> 1:2.2.5+dfsg-1) from testing while you using DOLFIN (version 1.0.0-1) >> >> from unstable, which was built against a newer libarmadillo2 package >> >> from unstable. I guess this is a problem you will see from time to >> >> time when mixing packages from testing and unstable. >> >> >> > No, it absolutely isn't. If libarmadillo2 exports new symbols then it >> > has to bump the version in its shlibs declaration. If it didn't do >> > that, this is a serious bug in that package. >> >> Yes, you are absolutely right. What I wrote above wasn't thought through. >> >> Johannes > > -- > Kumar Appaiah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org