On Fri, 2012-01-13 at 11:15 -0600, Pavan Balaji wrote:
On 01/12/2012 08:18 PM, Adam C Powell IV wrote:
Just tested a build, it seems to set the link properly, thanks very
much. Do you have a timetable for the release of 1.5.x?
1.5 GA will be released this summer, but alpha/beta/RC
On 01/12/2012 08:18 PM, Adam C Powell IV wrote:
Just tested a build, it seems to set the link properly, thanks very
much. Do you have a timetable for the release of 1.5.x?
1.5 GA will be released this summer, but alpha/beta/RC releases will be
out approximately every month.
-- Pavan
--
Hi Adam,
On 01/11/2012 04:10 PM, Adam C Powell IV wrote:
In what way are they breaking? We'd like to hear about such issues and
get them fixed.
See the previous emails: when one links a library or executable with
-lmpi, and libmpi.so is linked to libmpich.so, then it breaks with
undefined
On 01/12/2012 10:27 AM, Pavan Balaji wrote:
For the inter-library dependencies, I'd not like to have a Debian-only
patch. But you are right, libtool should be able to disable
dependencies on platforms it doesn't support. Let me look into this
some more.
Hmm.. In 1.5.x, it looks like we
tags 653616 patch
thanks
On Thu, 2012-01-12 at 10:39 -0600, Pavan Balaji wrote:
On 01/12/2012 10:27 AM, Pavan Balaji wrote:
For the inter-library dependencies, I'd not like to have a Debian-only
patch. But you are right, libtool should be able to disable
dependencies on platforms it
In that case, I'd suggest you explicitly list -lmpich, -lopa and -lmpl
in there for now. You can always look at mpicc -show for any released
version to figure out what all flags/libs are being set.
-- Pavan
On 01/07/2012 08:19 PM, Adam C Powell IV wrote:
That may be true, but it is a
Hello Pavan,
Thanks for your replies.
There's one other issue here, which is that Debian has an mpi-defaults
system which sets up symbolic links from /usr/lib/libmpi.so to either
the openmpi or mpich2 library, depending on the platform. That way, an
application can just use the mpi-default-dev
Hi Adam,
On 01/11/2012 12:26 PM, Adam C Powell IV wrote:
But since we made that switch that switch in early December, MPICH2 has
been breaking a number of package builds now which used to work with
LAM, and some of those breakages have been because of this issu.
In what way are they breaking?
Hello Pavan,
On Wed, 2012-01-11 at 12:49 -0600, Pavan Balaji wrote:
Hi Adam,
On 01/11/2012 12:26 PM, Adam C Powell IV wrote:
But since we made that switch that switch in early December, MPICH2 has
been breaking a number of package builds now which used to work with
LAM, and some of
That may be true, but it is a goal of Debian to be able to build the
archive using binutils-gold, which requires each ELF object (shared
library or executable) to link with every library whose symbol it uses.
As I understand it, the reason is that binutils-gold allows for much
faster build-time
X-DebBugs-CC: 653...@bugs.debian.org
Package: libmpich2-dev
Version: 1.4.1-1+b1
Greetings,
On mips(el) and s390, the scalapack build fails with:
gfortran -o
/build/buildd-scalapack_1.8.0-8-mipsel-D7TgwK/scalapack-1.8.0/TESTING/xspblas1tst
psblas1tst.o psblastst.o slamch.o pblastst.o
The best method is to use pkg-config to find what libraries need to be
linked in. Currently, this list is libmpich, libmpl and libopa, if you
are using generic TCP/IP and shared memory support. But if you enable
other modules, more libraries might be required.
-- Pavan
On 12/29/2011
12 matches
Mail list logo
