Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
Dear Julien, On Wed, Dec 21, 2011 at 10:29:55PM +0100, Julien Cristau wrote: 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. Shouldn't the dependencies save me from shooting myself in the foot like that, somehow ? Yes, this is a packaging bug in libarmadillo2, I reassigned this report there. After some discussion with upstream here is the summary: - Upstream will not raise the soname, since this, in their view, is does not warrant one. Their opinion is that armadillo's ABI isn't really for direct use by the end user, so a recompile should suffice. - They recommend eliminating all versions of the old libraries and rebuilding dolfin with the new ones. Now, this breaks existing installs of dolfin, so this is not an option. I am now wondering what the best course of action is. Do I create a new named package, or manually update the soname locally to Debian? Or, do I request removal of offending versions of the package, like upstream suggests? Thanks. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On 23 December 2011 02:19, Kumar Appaiah aku...@debian.org wrote: After some discussion with upstream here is the summary: - Upstream will not raise the soname, since this, in their view, is does not warrant one. Their opinion is that armadillo's ABI isn't really for direct use by the end user, so a recompile should suffice. - They recommend eliminating all versions of the old libraries and rebuilding dolfin with the new ones. To add to the above: I can understand the severity of an ABI breakage in a stable version such as Debian 6. It should never occur. However, the only official release is stable, as far as I understand how Debian works. There is no official release of unstable or testing. They are by definition (and their names) not guaranteed to be stable, as they are by design in flux until an official release. Building software on something named unstable and then using it on testing (or vice versa) is hence by definition not guaranteed to work. Dolfin will be broken only while the shared library in both unstable and testing is different. This is only temporary. As such, the version problem itself is only temporary. Rather than bumping the soname (which will have to be forever maintained by Debian), a quick solution is to simply propagate Armadillo 2.4.2 into both the unstable and testing streams. That way software such as Dolfin will never again get linked with the old v2.2, and hence there will be no version issues. I do not plan on adding any more ABI changes without bumping the soname. I'm not pleased that such ABI changes had to be done in the first place. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Thu, Dec 22, 2011 at 10:19:46 -0600, Kumar Appaiah wrote: Dear Julien, On Wed, Dec 21, 2011 at 10:29:55PM +0100, Julien Cristau wrote: 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. Shouldn't the dependencies save me from shooting myself in the foot like that, somehow ? Yes, this is a packaging bug in libarmadillo2, I reassigned this report there. After some discussion with upstream here is the summary: - Upstream will not raise the soname, since this, in their view, is does not warrant one. Their opinion is that armadillo's ABI isn't really for direct use by the end user, so a recompile should suffice. - They recommend eliminating all versions of the old libraries and rebuilding dolfin with the new ones. Now, this breaks existing installs of dolfin, so this is not an option. I am now wondering what the best course of action is. Do I create a new named package, or manually update the soname locally to Debian? Or, do I request removal of offending versions of the package, like upstream suggests? So I haven't actually *checked*, but from what I understood of this thread the ABI changes were compatible, which means there is and was no reason to bump the SONAME, only the version in the shlibs packaging metadata, for the added symbols in 2.4.2. This is not an upstream problem, it's a bug in the package, there is nothing for upstream to do here AFAIK. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Thu, Dec 22, 2011 at 06:04:03PM +0100, Julien Cristau wrote: Now, this breaks existing installs of dolfin, so this is not an option. I am now wondering what the best course of action is. Do I create a new named package, or manually update the soname locally to Debian? Or, do I request removal of offending versions of the package, like upstream suggests? So I haven't actually *checked*, but from what I understood of this thread the ABI changes were compatible, which means there is and was no reason to bump the SONAME, only the version in the shlibs packaging metadata, for the added symbols in 2.4.2. This is not an upstream problem, it's a bug in the package, there is nothing for upstream to do here AFAIK. That clears is up. I'll do the needful. Thanks. Sorry, Conrad, for causing the confusion. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Thu, Dec 22, 2011 at 11:08:13AM -0600, Kumar Appaiah wrote: So I haven't actually *checked*, but from what I understood of this thread the ABI changes were compatible, which means there is and was no reason to bump the SONAME, only the version in the shlibs packaging metadata, for the added symbols in 2.4.2. This is not an upstream problem, it's a bug in the package, there is nothing for upstream to do here AFAIK. That clears is up. I'll do the needful. Thanks. So, currently, the shlibs file reads: libarmadillo 2 libarmadillo2 Now, should I use a new package name, like libarmadillo2a, or so, which conflicts with libarmadillo2? I am unclear… Thanks. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Thu, Dec 22, 2011 at 11:12:45 -0600, Kumar Appaiah wrote: On Thu, Dec 22, 2011 at 11:08:13AM -0600, Kumar Appaiah wrote: So I haven't actually *checked*, but from what I understood of this thread the ABI changes were compatible, which means there is and was no reason to bump the SONAME, only the version in the shlibs packaging metadata, for the added symbols in 2.4.2. This is not an upstream problem, it's a bug in the package, there is nothing for upstream to do here AFAIK. That clears is up. I'll do the needful. Thanks. So, currently, the shlibs file reads: libarmadillo 2 libarmadillo2 Now, should I use a new package name, like libarmadillo2a, or so, which conflicts with libarmadillo2? I am unclear… No. Use something like: libarmadillo 2 libarmadillo2 (= 2.4.2) Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Thu, Dec 22, 2011 at 06:15:04PM +0100, Julien Cristau wrote: On Thu, Dec 22, 2011 at 11:12:45 -0600, Kumar Appaiah wrote: On Thu, Dec 22, 2011 at 11:08:13AM -0600, Kumar Appaiah wrote: So I haven't actually *checked*, but from what I understood of this thread the ABI changes were compatible, which means there is and was no reason to bump the SONAME, only the version in the shlibs packaging metadata, for the added symbols in 2.4.2. This is not an upstream problem, it's a bug in the package, there is nothing for upstream to do here AFAIK. That clears is up. I'll do the needful. Thanks. So, currently, the shlibs file reads: libarmadillo 2 libarmadillo2 Now, should I use a new package name, like libarmadillo2a, or so, which conflicts with libarmadillo2? I am unclear… No. Use something like: libarmadillo 2 libarmadillo2 (= 2.4.2) Thanks Julien. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
Hi. I just uploaded a package to (hopefully) fix this bug. Thanks for pointing it out. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Tue, Dec 20, 2011 at 12:32:05 -0500, Andreas Kloeckner wrote: On Wed, 21 Dec 2011 02:46:51 +1000, Conrad Sand conradsand...@gmail.com wrote: 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. Shouldn't the dependencies save me from shooting myself in the foot like that, somehow ? Yes, this is a packaging bug in libarmadillo2, I reassigned this report there. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
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:
Did, and it helped. Thanks very much!
Good!
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.
Cheers,
Julien
--
Julien Cristau julien.cris...@logilab.fr
Logilab http://www.logilab.fr/
Informatique scientifique gestion de connaissances
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
[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
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Wed, 21 Dec 2011 02:46:51 +1000, Conrad Sand conradsand...@gmail.com wrote: 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. Shouldn't the dependencies save me from shooting myself in the foot like that, somehow ? Andreas pgp3cX370M17b.pgp Description: PGP signature
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
Hi Andreas, Thank you for your report, but I couldn't reproduce your bug. On Tue, Dec 13, 2011 at 11:34 PM, Andreas Kloeckner inf...@tiker.net wrote: When I run any one of the simple fenics demos, I get this error message: ImportError: /usr/lib/libdolfin.so.1.0: undefined symbol: wrapper_dgesv_ This symbol is defined in the /usr/lib/libarmadillo.so.2 library from the libarmadillo2 package. ii libarmadillo21:2.2.5+dfsg-1 This is not the latest libarmadillo2 package from unstable. Could you upgrade and try again? Johannes -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Mon, 19 Dec 2011 09:54:09 +0100, Johannes Ring joha...@simula.no wrote: Hi Andreas, Thank you for your report, but I couldn't reproduce your bug. On Tue, Dec 13, 2011 at 11:34 PM, Andreas Kloeckner inf...@tiker.net wrote: When I run any one of the simple fenics demos, I get this error message: ImportError: /usr/lib/libdolfin.so.1.0: undefined symbol: wrapper_dgesv_ This symbol is defined in the /usr/lib/libarmadillo.so.2 library from the libarmadillo2 package. ii libarmadillo21:2.2.5+dfsg-1 This is not the latest libarmadillo2 package from unstable. Could you upgrade and try again? Did, and it helped. Thanks very much! This being as it is, could you upload a new package with tightened dependencies? Thanks, Andreas pgpEKqPWqO23L.pgp Description: PGP signature
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Mon, Dec 19, 2011 at 10:37 AM, Andreas Kloeckner inf...@tiker.net wrote:
Did, and it helped. Thanks very much!
Good!
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.
Johannes
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Mon, 19 Dec 2011 12:46:46 +0100, Johannes Ring joha...@simula.no wrote:
On Mon, Dec 19, 2011 at 10:37 AM, Andreas Kloeckner inf...@tiker.net wrote:
Did, and it helped. Thanks very much!
Good!
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.
Hmm, I feel like automatic shared library dependencies should have been
able to catch this, i.e. someone is supposed to have done something with
the soname at some point--I'm just not sure what... :)
In any case, thanks very much for your help!
Andreas
pgp5kG5cUR6wI.pgp
Description: PGP signature
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Mon, Dec 19, 2011 at 3:50 PM, Andreas Kloeckner inf...@tiker.net wrote: Hmm, I feel like automatic shared library dependencies should have been able to catch this, i.e. someone is supposed to have done something with the soname at some point--I'm just not sure what... :) Yes, I agree. It is most likely an ABI incompatible change in Armadillo library and the soname should have been updated in one of the latest uploads. In any case, thanks very much for your help! No problem. Should I close this bug report, or do you want to re-target it somewhere else? Johannes -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
On Mon, 19 Dec 2011 16:13:00 +0100, Johannes Ring joha...@simula.no wrote: On Mon, Dec 19, 2011 at 3:50 PM, Andreas Kloeckner inf...@tiker.net wrote: Hmm, I feel like automatic shared library dependencies should have been able to catch this, i.e. someone is supposed to have done something with the soname at some point--I'm just not sure what... :) Yes, I agree. It is most likely an ABI incompatible change in Armadillo library and the soname should have been updated in one of the latest uploads. In any case, thanks very much for your help! No problem. Should I close this bug report, or do you want to re-target it somewhere else? Do as you feel is best. I guess we might as well put whoever packaged libarmadillo in the loop. Maybe they can teach their upstream about sonames. :) Thanks again, Andreas pgpoCYG0s2KDB.pgp Description: PGP signature
Bug#651997: python-dolfin: unknown symbol: wrapper_dgesv_
Package: python-dolfin Version: 1.0.0-1 Severity: grave Justification: renders package unusable Dear Maintainer, When I run any one of the simple fenics demos, I get this error message: ImportError: /usr/lib/libdolfin.so.1.0: undefined symbol: wrapper_dgesv_ For definiteness, I used this program here: http://fenicsproject.org/documentation/tutorial/fundamentals.html#the-poisson-equation (scroll down a bit) Thanks, Andreas -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-rc4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-dolfin depends on: ii libamd2.2.0 1:3.4.0-2 ii libarmadillo21:2.2.5+dfsg-1 ii libarpack2 2.1+parpack96.dfsg-4 ii libblas3gf [libblas.so.3gf] 1.2.20110419-2 ii libboost-filesystem1.46.11.46.1-7+b1 ii libboost-iostreams1.46.1 1.46.1-7+b1 ii libboost-math1.46.1 1.46.1-7+b1 ii libboost-mpi1.46.1 1.46.1-7+b1 ii libboost-program-options1.46.1 1.46.1-7+b1 ii libboost-serialization1.46.1 1.46.1-7+b1 ii libboost-system1.46.11.46.1-7+b1 ii libboost-thread1.46.11.46.1-7+b1 ii libc62.13-21 ii libcamd2.2.0 1:3.4.0-2 ii libccolamd2.7.1 1:3.4.0-2 ii libcholmod1.7.1 1:3.4.0-2 ii libcolamd2.7.1 1:3.4.0-2 ii libdolfin1.0 1.0.0-1 ii libdolfin1.0-dev 1.0.0-1 ii libgcc1 1:4.6.2-5 ii libgomp1 4.6.2-5 ii liblapack3gf [liblapack.so.3gf] 3.3.1-1 ii libopenmpi1.31.4.3-2.1 ii libpetsc3.1 3.1.dfsg-11 ii libptscotch-5.1 5.1.11.dfsg-7 ii libpython2.6 2.6.7-4 ii libpython2.7 2.7.2-8 ii libslepc3.1 3.1-p6.dfsg-1 ii libstdc++6 4.6.2-5 ii libumfpack5.4.0 1:3.4.0-2 ii libxml2 2.7.8.dfsg-5 ii python 2.7.2-9 ii python-ffc 1.0.0-1 ii python-instant 1.0.0-1 ii python-numpy 1:1.5.1-3 ii python-ufc 2.0.5-1 ii python-ufl 1.0.0-1 ii python-viper 1.0.0-1 ii python2.62.6.7-4 ii python2.72.7.2-8 ii swig2.0 2.0.4-4 ii zlib1g 1:1.2.3.4.dfsg-3 python-dolfin recommends no packages. Versions of packages python-dolfin suggests: ii dolfin-doc 1.0.0-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
