Atlas-lapack discussion

Question

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.

Answer 1

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)