On Thu, Nov 6, 2008 at 3:08 PM, Ei-ji Nakama <[EMAIL PROTECTED]> wrote:
> Hi
>
> 2008/11/6 Anand Patil <[EMAIL PROTECTED]>:
> > I tried that earlier, and it doesn't encounter the zdotu error (maybe it
> was
> > fixed in 10.0.5?) but I got a different error:
>
> no, see MKL manual.
> Because fortra
Hi
2008/11/6 Anand Patil <[EMAIL PROTECTED]>:
> I tried that earlier, and it doesn't encounter the zdotu error (maybe it was
> fixed in 10.0.5?) but I got a different error:
no, see MKL manual.
Because fortran do not have compatibility, You appoint ABI of your
Fortran in a link of MKL.
> /opt/in
On Thu, Nov 6, 2008 at 2:01 AM, Ei-ji Nakama <[EMAIL PROTECTED]> wrote:
> Hi
>
> If you want to use MKL10(no 8 or 9), you should obey instructions of
> R-admin.
> MKL10 needs openmp. This needs gcc4.2 or later.
> OpenMP for Intel was necessary with MKL10.0.1.x (There was not it in a
> manual of M
On Thu, 6 Nov 2008, Anand Patil wrote:
On Thu, Nov 6, 2008 at 6:48 AM, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
And how does that help you? At some future point on a real problem you
will get
incorrect answers/segfault.
That test was put there as a result of such incorre
On Thu, Nov 6, 2008 at 6:48 AM, Prof Brian Ripley <[EMAIL PROTECTED]>wrote:
> And how does that help you? At some future point on a real problem you
> will get incorrect answers/segfault.
>
> That test was put there as a result of such incorrect results found the
> hard way.
>
I appreciate that.
And how does that help you? At some future point on a real problem you
will get incorrect answers/segfault.
That test was put there as a result of such incorrect results found the
hard way.
On Wed, 5 Nov 2008, Anand Patil wrote:
Scratch that- finally got it working! The steps were:
- Chang
Scratch that- finally got it working! The steps were:
- Change configure to 'break the thermometer' as suggested:
===
--- configure (revision 46843)
+++ configure (working copy)
@@ -37473,6 +37473,8 @@
fi
+r_cv_zdotu_is_usable=y
Thanks for your help, everyone. I was using gcc previously, but building
with the Intel compilers causes its own problems:
/opt/intel/cce/10.1.018/lib/libguide.so: undefined reference to
`pthread_atfork'
make[3]: *** [R.bin] Error 1
make[3]: Leaving directory `/working_copies/R/src/main'
make[2]: *
Quoting Peter Dalgaard <[EMAIL PROTECTED]>:
> Anand Patil wrote:
> > On Wed, Nov 5, 2008 at 5:59 PM, Martyn Plummer <[EMAIL PROTECTED]> wrote:
> >
> >> It looks like the em64t version of MKL fails the test for the accuracy
> >> of zdotu ("checking whether double complex BLAS can be used") and is
>
Anand Patil wrote:
> On Wed, Nov 5, 2008 at 5:59 PM, Martyn Plummer <[EMAIL PROTECTED]> wrote:
>
>> It looks like the em64t version of MKL fails the test for the accuracy
>> of zdotu ("checking whether double complex BLAS can be used") and is
>> therefore dropped in favour of R's built-in BLAS. I
You can't link 32-bit libraries into 64-bit code.
That test is not for accuracy but for compatible return conventions.
What compilers are in use here? We've seen several instances of gcc and
icc not being compatible on x86_64 (Linux and Mac OS X: not surprising as
gcc3 and gcc4 are also not c
On Wed, Nov 5, 2008 at 5:59 PM, Martyn Plummer <[EMAIL PROTECTED]> wrote:
> It looks like the em64t version of MKL fails the test for the accuracy
> of zdotu ("checking whether double complex BLAS can be used") and is
> therefore dropped in favour of R's built-in BLAS. I have just tested
> this o
It looks like the em64t version of MKL fails the test for the accuracy
of zdotu ("checking whether double complex BLAS can be used") and is
therefore dropped in favour of R's built-in BLAS. I have just tested
this on Fedora and get the same result.
The 32-bit MKL does work for me.
Martyn
On Wed
On Tue, Nov 4, 2008 at 7:34 PM, <[EMAIL PROTECTED]> wrote:
> I can see a couple of problems:
>
> 1) No "-lpthread" in --with-blas
> 2) No "-L" prefix in the library path in --with-lapack
>
> In addition, I don't think you need to add -lmkl to --with-lapack,
> although that is probably harmless.
>
14 matches
Mail list logo
