Bug#854228: Libraries not linked with their deps

2017-07-25 Thread Drew Parsons 
On Tue, 21 Mar 2017 11:03:07 +0800 Drew Parsons 
wrote:
> On Tue, 21 Mar 2017 10:50:29 +0800 Drew Parsons 
> wrote:
> > 
> > That document is from 1997 though.  The MPI standard has moved
> through
> > 2 major versions since then. But blacs remains unchanged.
> 
> Further, BLACS is now part of (packaged with) scalapack, see
> http://netlib.org/scalapack/scalapack-2.0.0.html#_7_3_blacs_revamping
> 
> Probably the solution we want is to update our scalapack to 2.0.2,
and
> remove this blacs package, at least as a separate source package.


Confirming this is fixed in scalapack 2.0 (2.0.2-1exp3 is now in
experimental.

The initialisation code in BLACS/SRC/blacs_pinfo_.c now no longer
depends on whether Main is in F77 or not, i.e. the single 
libscalapack-openmpi.so library should be sufficient for use from both
C (via Cblacs_pinfo) or Fortran (via blacs_pinfo_).

Will close this bug when scalapack 2.0 transitions into unstable.

Drew

Bug#854228: Libraries not linked with their deps

2017-03-25 Thread Muammar El Khatib 
Dear all,

On Mon, Mar 20, 2017 at 11:03 PM, Drew Parsons  wrote:
> Probably the solution we want is to update our scalapack to 2.0.2, and
> remove this blacs package, at least as a separate source package. That
> won't happen for stretch, obviously.

I am sorry for the delay in replying to this report. I am right now
preparing to upload a Debian revision that adds the patch in #848813
for fixing the FTBFS.

Lately, I have had limited time to take care of ScaLAPACK, and I think
it is time to move it to team maintenance. I was thinking of
Debian-science. I have already sent an email to the mailing list.

Regards,
-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#854228: Libraries not linked with their deps

2017-03-20 Thread Drew Parsons 
On Tue, 21 Mar 2017 10:50:29 +0800 Drew Parsons 
wrote:
> 
> That document is from 1997 though.  The MPI standard has moved
through
> 2 major versions since then. But blacs remains unchanged.

Further, BLACS is now part of (packaged with) scalapack, see
http://netlib.org/scalapack/scalapack-2.0.0.html#_7_3_blacs_revamping

Probably the solution we want is to update our scalapack to 2.0.2, and
remove this blacs package, at least as a separate source package. That
won't happen for stretch, obviously.

Drew

Bug#854228: Libraries not linked with their deps

2017-03-20 Thread Drew Parsons 
On Wed, 08 Feb 2017 14:25:12 +0100 =?ISO-8859-1?Q?S=E9bastien?=
Villemot  wrote:
> 
> I don't know what's the proper solution to this issue. The
circularity
> can easily be dealt with (using patchelf for closing the loop in
> DT_NEEDED entries).
> 
> The problem is rather that the Cblacs_pinfo symbol is provided by two
> alternative (and mutually exclusive) libraries. Input from the
> maintainer would be helpful here.


There is some discussion upstream at 
http://www.netlib.org/blacs/mpiblacs_issues.ps

They say the alternative libraries are needed for invoking MPI_INIT.
Since blacs doesn't know which language you'll be accessing it with, it
can only be determined at link time by linking against either
blacsCinit* or blacsF77init*. They're saying it's a constraint of the
MPI standard.  

That document is from 1997 though.  The MPI standard has moved through
2 major versions since then. But blacs remains unchanged.

Drew

Bug#854228: Libraries not linked with their deps

2017-02-08 Thread Sébastien Villemot 
Le mercredi 08 février 2017 à 17:48 +0500, Andrey Rahmatullin a écrit :
> On Wed, Feb 08, 2017 at 01:21:13PM +0100, Sébastien Villemot wrote:
> > By the way, does this bug really warrant a serious severity? I could not
> > find anything in the Policy mandating proper linking of shared libraries
> > within the same package.
> You are correct, "within the same package" is not a part of the
> requirement.
> Besides the Policy requirement of "shared libraries must be linked against
> all libraries that they use symbols from in the same way that binaries
> are" in 10.2 there is an additional "Shared libraries must normally be
> linked with all libraries they use symbols from" requirement in
> https://release.debian.org/stretch/rc_policy.txt.

Thanks. I had overlooked the requirement spelled out in Policy §10.2.
Actually it confirms that this bug is actually of RC severity.

I don't know what's the proper solution to this issue. The circularity
can easily be dealt with (using patchelf for closing the loop in
DT_NEEDED entries).

The problem is rather that the Cblacs_pinfo symbol is provided by two
alternative (and mutually exclusive) libraries. Input from the
maintainer would be helpful here.

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594

Bug#854228: Libraries not linked with their deps

2017-02-08 Thread Andrey Rahmatullin 
On Wed, Feb 08, 2017 at 01:21:13PM +0100, Sébastien Villemot wrote:
> By the way, does this bug really warrant a serious severity? I could not
> find anything in the Policy mandating proper linking of shared libraries
> within the same package.
You are correct, "within the same package" is not a part of the
requirement.
Besides the Policy requirement of "shared libraries must be linked against
all libraries that they use symbols from in the same way that binaries
are" in 10.2 there is an additional "Shared libraries must normally be
linked with all libraries they use symbols from" requirement in
https://release.debian.org/stretch/rc_policy.txt.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#854228: Libraries not linked with their deps

2017-02-08 Thread Sébastien Villemot 
On Sun, 5 Feb 2017 15:49:32 +0500 Andrey Rahmatullin  wrote:
> On Sun, Feb 05, 2017 at 02:09:40PM +0500, Andrey Rahmatullin wrote:
> > undefined symbol: Cblacs_pinfo  (/usr/lib/libblacs-openmpi.so.1.1)
> This one is defined in other two libs in the package.
> 
> > undefined symbol: BI_Iam(/usr/lib/libblacsCinit-openmpi.so.1.1)
> > undefined symbol: BI_F77_MPI_COMM_WORLD 
> > (/usr/lib/libblacsCinit-openmpi.so.1.1)
> > undefined symbol: BI_Np (/usr/lib/libblacsCinit-openmpi.so.1.1)
> > undefined symbol: bi_f77_get_constants_ 
> > (/usr/lib/libblacsCinit-openmpi.so.1.1)
> > undefined symbol: BI_BlacsErr   (/usr/lib/libblacsCinit-openmpi.so.1.1)
> > 
> > undefined symbol: BI_Iam(/usr/lib/libblacsF77init-openmpi.so.1.1)
> > undefined symbol: BI_F77_MPI_COMM_WORLD (/usr/lib/libblacsF77init-
> > openmpi.so.1.1)
> > undefined symbol: BI_Np (/usr/lib/libblacsF77init-openmpi.so.1.1)
> > undefined symbol: bi_f77_get_constants_ (/usr/lib/libblacsF77init-
> > openmpi.so.1.1)
> > undefined symbol: bi_f77_init_  (/usr/lib/libblacsF77init-openmpi.so.1.1)
> These ones are defined in the other library in the package.
> 
> So this is is a circular dependency, unfortunately.

The fact that Cblacs_pinfo is provided by both
libblac{C,F77}init-openmpi looks intentional: one or the other should be
chosen at link time, depending on your preferred interface (C or F77).

Hence, it is not possible to enforce the dependency of libblacs-openmpi
on one or the other without breaking this flexibility.

By the way, does this bug really warrant a serious severity? I could not
find anything in the Policy mandating proper linking of shared libraries
within the same package.

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594

Bug#854228: Libraries not linked with their deps

2017-02-05 Thread Andrey Rahmatullin 
On Sun, Feb 05, 2017 at 02:09:40PM +0500, Andrey Rahmatullin wrote:
> undefined symbol: Cblacs_pinfo  (/usr/lib/libblacs-openmpi.so.1.1)
This one is defined in other two libs in the package.

> undefined symbol: BI_Iam(/usr/lib/libblacsCinit-openmpi.so.1.1)
> undefined symbol: BI_F77_MPI_COMM_WORLD 
> (/usr/lib/libblacsCinit-openmpi.so.1.1)
> undefined symbol: BI_Np (/usr/lib/libblacsCinit-openmpi.so.1.1)
> undefined symbol: bi_f77_get_constants_ 
> (/usr/lib/libblacsCinit-openmpi.so.1.1)
> undefined symbol: BI_BlacsErr   (/usr/lib/libblacsCinit-openmpi.so.1.1)
> 
> undefined symbol: BI_Iam(/usr/lib/libblacsF77init-openmpi.so.1.1)
> undefined symbol: BI_F77_MPI_COMM_WORLD (/usr/lib/libblacsF77init-
> openmpi.so.1.1)
> undefined symbol: BI_Np (/usr/lib/libblacsF77init-openmpi.so.1.1)
> undefined symbol: bi_f77_get_constants_ (/usr/lib/libblacsF77init-
> openmpi.so.1.1)
> undefined symbol: bi_f77_init_  (/usr/lib/libblacsF77init-openmpi.so.1.1)
These ones are defined in the other library in the package.

So this is is a circular dependency, unfortunately.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#854228: Libraries not linked with their deps

2017-02-05 Thread Andrey Rahmatullin 
Package: libblacs-openmpi1
Version: 1.1-37+b1
Severity: serious

All three shared libs in the package are linked only with libc, while using
various MPI_*, BI_* etc symbols.

Interesting that rebuilding a package (with the patch for #848813) links these
libraries with various libmpi_* libs, partially fixing the problem. These are
the remaining symbols:

undefined symbol: Cblacs_pinfo  (/usr/lib/libblacs-openmpi.so.1.1)

undefined symbol: BI_Iam(/usr/lib/libblacsCinit-openmpi.so.1.1)
undefined symbol: BI_F77_MPI_COMM_WORLD (/usr/lib/libblacsCinit-openmpi.so.1.1)
undefined symbol: BI_Np (/usr/lib/libblacsCinit-openmpi.so.1.1)
undefined symbol: bi_f77_get_constants_ (/usr/lib/libblacsCinit-openmpi.so.1.1)
undefined symbol: BI_BlacsErr   (/usr/lib/libblacsCinit-openmpi.so.1.1)

undefined symbol: BI_Iam(/usr/lib/libblacsF77init-openmpi.so.1.1)
undefined symbol: BI_F77_MPI_COMM_WORLD (/usr/lib/libblacsF77init-
openmpi.so.1.1)
undefined symbol: BI_Np (/usr/lib/libblacsF77init-openmpi.so.1.1)
undefined symbol: bi_f77_get_constants_ (/usr/lib/libblacsF77init-
openmpi.so.1.1)
undefined symbol: bi_f77_init_  (/usr/lib/libblacsF77init-openmpi.so.1.1)



-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libblacs-openmpi1 depends on:
ii  libc62.24-9
ii  mpi-default-bin  1.8

libblacs-openmpi1 recommends no packages.

libblacs-openmpi1 suggests no packages.

-- debconf-show failed