Opened 14 years ago

Closed 13 years ago

#823 closed defect (fixed)

make atlas standard in Sage

Reported by: was Owned by: mabshoff
Priority: major Milestone: sage-2.9
Component: packages: standard Keywords:
Cc: Merged in:
Authors: Reviewers:
Report Upstream: Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by mabshoff)

Merged in 2.9.alpha6.

Change History (12)

comment:1 Changed 14 years ago by was

  • Milestone changed from sage-2.9 to Sage-2.10

comment:2 Changed 14 years ago by mabshoff

  • Status changed from new to assigned

comment:3 Changed 14 years ago by was

  • Milestone changed from Sage-2.10 to sage-2.9

comment:4 Changed 14 years ago by mabshoff

What needs to be done:

  • update to 3.8.0
  • use sage_fortran to build the f77 wrapper, the flag --no-f77 doesn't work properly
  • build a complete Lapack by using netlib.org's F77 Lapack

Getting ATLAS into Sage will probably be a coding sprint project during SD6.

Cheers,

Michael

comment:5 Changed 13 years ago by jkantor

new package that should resolve all these issues.

http://sage.math.washington.edu/spkgs/atlas-3.8.spkg

One important point. For atlas to build a correct lapack, we must have already built an lapack and then merge with atlas libs to get a full one. On OSX we don't build lapack so the above package will fail. To use the above on OSX first install this spkg

http://sage.math.washington.edu/spkgs/lapack-20071123.spkg

This will build lapack even on OSX. Then atlas can be installed.

Also on OSX even with atlas installed, numpy and scipy build against the accelerate framework still.

comment:6 Changed 13 years ago by jkantor

I just noticed that building the cvxopt package with this atlas causes a missing symbol error for the cvxopt package

_g95_ioparm

I'm mystified by this. Need to investigate.

comment:7 Changed 13 years ago by jkantor

Ignore the cvxopt package issue, it was a mistake on my part, I think atlas is ready to go.

comment:8 Changed 13 years ago by jkantor

the atlas3.8 package didn't have mabshoff's patch so that the shared objects are copied by make install

http://sage.math.washington.edu/home/jkantor/spkgs/atlas-3.8.p1.spkg

comment:9 Changed 13 years ago by jkantor

Problem:

Atlas does not build shared libraries on OSX.

THis is because on OSX the atlas build script does

ld -melf_i386 -shared -soname libatlas.so -o libatlas.so \

--whole-archive libatlas.a --no-whole-archive -lc -lm

ld: unknown flag: -melf_i386

This is a problem with atlas not knowing that on osx we don't want elf,

probably should be -dynamiclib or something.

comment:10 Changed 13 years ago by jkantor

On OSX the ld options --whole_archive don't exist.

The following appears to produce a shared atlas from the static one

ld -dylib -o libatlas.dylib -lm -lc -all_load libatlas.a

(-L must be set appropriately)

comment:11 Changed 13 years ago by jkantor

New package

http://sage.math.washington.edu/home/jkantor/atlas-3.8.p2.spkg

This package fixes problems with the shared libraries lapack creates on linux (the lapack.so doesn't not have the same symbols as lapack.a)

It also creates libatlas and libcblas shared on OSX using the trick in the previous comment, but I have not yet resolved how to make libf77blas or liblapack shared on OSX. It might be best to not do this on OSX till we create the whole thing. Thoughts

comment:12 Changed 13 years ago by mabshoff

  • Description modified (diff)
  • Milestone changed from sage-2.10.1 to sage-2.9
  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.