Atlas-lapack discussion

gborzi · 2010-12-18 00:12:51

I'm the maintainer of the atlas-lapack package in AUR https://aur.archlinux.org/packages.php?ID=16575. I've adopted it following a request of the previous maintainer.
I'd like to do some changes to the package, but before uploading a new PKGBUILD I'd like to discuss the changes I've in mind with the those interested.
Here is the list of changes:
1) Only shared build: currently the PKGBUILD compiles ATLAS sources two times, one for static libraries and one for shared libraries, where the -fPIC option is passed to the compiler. In order to speed up the compilation I would like to remove the static build. Static libraries (*.a) will be still available, but the code is compiled with -fPIC.
2) Remove unneeded libraries: currently the compiled package contains multi-threaded (libptf77blas, libptcblas) and single-threaded (libf77blas, libcblas) libraries. I suggest that on single processor machines the multi-threaded libraries are removed, and on multi processor machines the single-threaded libraries are removed and the multi-threaded libraries are renamed like the corresponding single-threaded ones, i.e.
libptf77blas => libf77blas, libptcblas => libcblas
Also libblas.so will point to libf77blas.
3) Remove static libraries: I'm not sure about this last point. I think it doesn't make sense to make a static link with atlas. Moving a statically linked binary to another CPU-architecture will almost surely results in failure, i.e. the binary won't work.
Here is the new source package I've made http://aur.pastebin.com/pB5Y3eyJ
Comments and suggestions are welcome.

mickele · 2010-12-18 16:13:21

Hi Giuseppe.
I report here some ideas about your suggestions.
For point 1, if you build static libraries with option -fPIC, there are problems in link phase (look at comment of darenw on Wed, 06 Oct 2010 on atlas-lapack AUR page).
For point 3, build process of some applications requires static libraries: it's possible to modify build scripts to avoid this problem, but it's not so easy, also because of other linking problem that can occur. Comment of darenw is again an example of this type of problem.
For point 2, usually I prefer respecting original name conventions, to avoid problems with applications that require multithreaded support. However for ATLAS I don't think that your suggestion should cause many troubles.

PS: Thanks again for having adopted atlas-lapack!

Last edited by mickele (2010-12-18 16:27:46)

gborzi · 2010-12-18 22:05:38

Thanks for your answer mickele. In a later comment on Oct. 7 darenw said that it wasn't a problem with atlas-lapack, rather with a stray library file in his filesystem. I've tested the static library compiled with -fPIC and works fine so far.

mickele · 2010-12-19 14:04:23

Oops, you're right, I had misunderstood that message.
So it's no more necessary to build twice the library.

Last edited by mickele (2010-12-19 14:16:40)

goodgrue · 2011-01-26 10:15:30

I just installed atlas-lapack from the AUR, and now when I try to recompile python2-numpy the build fails because it's looking for the multithreaded libraries (e.g. ptf77blas.so), but they've all been renamed. Perhaps it would be better to stick with the original naming scheme after all.

gborzi · 2011-01-26 10:55:39

Hi goodgrue,
I have just recompiled python2-numpy and python3-numpy from abs with atlas-lapack 3.8.3-10 and it worked fine. Perhaps you have removed the "export Atlas=None" in PKGBUILD.
I checked some .so files in the package and these are correctly linked to atlas-lapack libraries. Do you know how to test the numpy package?

goodgrue · 2011-01-26 22:48:36

Oops, you are correct -- I had removed that line from the PKGBUILD. Sorry about that; I thought I had put it back in before my most recent build.

eca · 2011-02-01 22:52:07

Im on a single core cpu. During test in build, I had to kill testdlamch and testslamch because they would not stop. I also removed all occurrences of libpt* in makefile.shared(make would halt due to "no target for ptf77blas"), and updated its md5 in pkgbuild. Seems to work.

gborzi · 2011-02-02 15:28:38

Thanks for your comment Eca. I have not a single core CPU to test the package, so I didn't know that libpt* libraries weren't built on single core. I'll update the package soon.

Arch Linux

#1 2010-12-18 00:12:51

Atlas-lapack discussion

#2 2010-12-18 16:13:21

Re: Atlas-lapack discussion

#3 2010-12-18 22:05:38

Re: Atlas-lapack discussion

#4 2010-12-19 14:04:23

Re: Atlas-lapack discussion

#5 2011-01-26 10:15:30

Re: Atlas-lapack discussion

#6 2011-01-26 10:55:39

Re: Atlas-lapack discussion

#7 2011-01-26 22:48:36

Re: Atlas-lapack discussion

#8 2011-02-01 22:52:07

Re: Atlas-lapack discussion

#9 2011-02-02 15:28:38

Re: Atlas-lapack discussion

Board footer