Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_

[Conrad Sand]

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 <akumar at 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.cristau at 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 <inform at 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