[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: reliable seg fault
From: |
Thomas Weber |
Subject: |
Re: reliable seg fault |
Date: |
Tue, 25 Oct 2011 17:33:10 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Oct 25, 2011 at 12:50:48AM -0500, Mike Miller wrote:
> On Mon, 24 Oct 2011, Thomas Weber wrote:
>
> >On Mon, Oct 24, 2011 at 02:08:45AM -0500, Mike Miller wrote:
> >>I'm guessing the problem is with libraries or with LAPACK or ATLAS.
> >
> >Build Octave against the reference BLAS and LAPACK and try again.
> >If that works, use LD_PRELOAD to get the linker into prefering
> >ATLAS. If it then crashes, you know it's ATLAS.
>
>
> Thanks for these tips about ATLAS and gcc. I found this right away,
> but it seems to be about x86 instead of x86_64:
>
> http://math-atlas.sourceforge.net/errata.html#gccCrazy
>
> It looks like 3.8.4 is the newest stable release and I have 3.8.3,
> which is two years older. Maybe I should try updating ATLAS. I
> think the sys admin might have had trouble installing ATLAS because
> I see these two subdirectories next to each other in /export/apps:
>
> drwxr-xr-x 4 root root 4096 May 21 2010 /export/apps/atlas-3.8.3/
> drwxr-xr-x 4 root root 4096 Jan 13 2010 /export/apps/atlas-3.8.3-orig/
>
>
> Another question: Isn't there a command that can be run within
> Octave, or maybe a command-line option when calling Octave, that
> tells us something about how it was compiled?
No idea, but it wouldn't help in the ATLAS case. You are free to build
Octave against the reference BLAS and LAPACK libraries and then later
(at runtime) let the linker prefer ATLAS (in fact, we do this in
Debian). The interface is compatible.
So, no compile time information will help you in this case, as ATLAS
wasn't even installed at build time.
Thomas