Hey Folks,
Anyone got ScaLapack and BLACS working and not just compiled under
OSX10.5 in 64-bit mode?
The FAQ site directions were followed and every thing compiles just
fine. But ALL of the single precision routines and many of the double
precisions routines in the TESTING directory fail w
trying something similar with Solaris and 64-bit
on
a SPARC machine and was seeing segv's inside the MPI Library due to a
pointer being passed through an integer (thus dropping the upper 32
bits). Funny thing is it all works under Solaris on AMD64 or IA-64
platforms.
--td
Date: Thu, 28 F
All,
I really didn't want to start a new thread discussing the virtues and
vices of every compiler, since this is hardly my forte and the
opportunity to offend someone is fairly high, whilst making myself
look clownish
What I should have said was that "for my organization one cannot
ju
OK folks,
Whilst testing cases of ratcheting up memory usage under Mac OSX
Leopard I ran into a peculiar problem of segmentation faults that just
should not be happening. I whittled down the code to find where the
error took place and well, for this simple code...
#include
#include
int
l of
memory usage I was incurring. I'm assuming more stack is chewed up in
overhead as compared to serial code. Yes/No?
Again sorry for the faulty memory and seemingly stupid question!
Regards,
Greg
On Apr 25, 2008, at 4:10 PM, Brian Barrett wrote:
On Apr 25, 2008, at 2:06 PM, Gregor
Points to clarify if I may, having gone through this relatively
recently:
g77 and gfortran are NOT one and the same.
gfortran from sourceforge works well, but it is based on gnu gcc 4.3
and not on the gnu gcc 4.0.1 that comes with Leopard.
Your best bet is to download the ENTIRE gcc package fr
ed symbols:
"_ATL_slauum", referenced from:
_test_inv in sinvtst.o
"_ATL_strtri", referenced from:
_test_inv in sinvtst.o
"_ATL_spotrf", referenced from:
_test_inv in sinvtst.o
"_ATL_sgetrf", referenced from:
_test_inv in sinvtst.o
"_ATL_sgetri&qu
