On Feb 20, 9:20 pm, William Stein <wst...@gmail.com> wrote:
> On Fri, Feb 20, 2009 at 9:14 PM, mabshoff <mabsh...@googlemail.com> wrote:
<SNIP>
> > Because at some point there was a failure the makefile errors out at
> > the very end even though it all worked. So the script you wrote is
> > likely to hit the same bug unless you completely clean out the ATLAS
> > build directory.
>
> > The fix here is to figure out which file causes the tuning failure
> > message in the end and to get rid of it before restart.
>
> > Thoughts?
>
> My script deletes the entire ATLAS-build directory, so it works.
Ok, I hadn't taken too close a look at the new spkg yet.
> I just tested doing builds of the ATLAS spkg here all at once on boxen
> and everything worked perfectly. There were a total of five separate
> complete restarts, but after doing them everything finished building
> perfectly.
Good.
> Anyway, I build Sage a lot on loaded systems, and I just want
> something that actually works, since this "restart since system is too
> loaded" ATLAS build issue has literally been causing me pain and
> suffering for over a year now. I know from tons of experience that
> simply restarting from scratch the build of that package nearly always
> works, since I have to do it a lot manually when doing build testing
> and building Sage binaries.
>
> I don't care what you do to get this to work. Just fix it or use my spkg:
>
> http://sage.math.washington.edu/home/wstein/patches/atlas-3.8.3.p1.spkg
>
> I can easily test any proposed spkg.
Well, it might not be as elegant as my solution and I think in some
circumstances you will have a hard time getting ATLAS to work with
this approach at all, but given that we need to get 3.3 out and it is
a lot better than before I am fine with shipping 3.3 with that spkg.
Once I have some more time I think I will revisit this since I believe
the fix is a one line addition to my version of spkg-install will
avoid the reported problem and the incremental build is more elegant
than the "scorched earth" approach you are taking :p. But you can't
argue with working code.
In either case, this code as well as my solution does not account for
actually checking if the issue was a tuning error in the first place
which I have some ideas for to figure out. But that will be dealt with
via another ticket. Note that I have seen ATLAS break due to an
assembler bug in 32 bit Solaris x86 builds, but that has long since
been fixed and upstreamed. The 64 bit build on Solaris x86 was not
affected with the same assembler, so it was an entertaining journey
into the binutils sources to figure this out.
Another somewhat relevant problem here is also that the default gcc on
SiCortex blows up building ATLAS, so the current spkg rebuilds itself
10 times and will fail in exactly the same way. But this is an exotic
platform and will not affect anyone who should know better in the
first place since SoCortex boxen aren't exactly commen systems for the
average joe :). I am not aware of any other compiler that fails
building ATLAS, so this is not something we will have to deal with
frequently.
> -- William
Cheers,
Mcihael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
