Bug#854228: Libraries not linked with their deps
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
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
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
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
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
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
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
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
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