Hi I'm kind of picking up the thread again from bugs 1819 and 9081.... At the minute there exists ebuilds for LAPACK, BLAS and ATLAS. LAPACK depends on BLAS and using ATLAS is mutually exclusive - the reason being ATLAS provides a partial optimised LAPACK library which a LAPACK ebuild will completely overwrite. Some effort to fix this was made in bug 9081 but this doesn't seem to have been incorporated in the latest ATLAS-3.4.1 ebuild. And correctly so! This ebuild provides a pretty stock ATLAS installation. The trouble comes with the LAPACK ebuild.... I've written a new LAPACK-3.0 ebuild which a) depends on ATLAS rather than BLAS, b) actually performs some testing to make sure the library is built properly and c) builds the optimised LAPACK library based on ATLAS. The rationale follows: People really shouldn't be using the F77 BLAS package for anything serious given that it is not well optimised. This is documented in the LAPACK and BLAS packages. The use of an optimised ATLAS is waay preferable and no conflicts arise at all in using ATLAS and LAPACK together. Also, this way round, a user can install all three packages should he/she wish without conflicts - the only proviso being that if a user wants to link against LAPACK, he also has to link against ATLAS rather than BLAS. Finally, this is an improvment on the atlas-3.4.1 ebuild submitted in bug 9081 - this ebuild effectively combined the builds of ATLAS and LAPACK and doesn't allow package differentiation. The attached ebuild performs the BLAS library testing and the installation, build and testing of the LAPACK routines. I haven't included the timing make steps as these kept segfaulting on my laptop but it's probably worth including these as well. The aim of all this was to try and get a SciPy ebuild working but this depends firstly on having ATLAS and LAPACK set up correctly! Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 10201 [details] lapack-3.0.ebuild
Created attachment 10202 [details] lapack-3.0.ebuild
this does not seem to be a kde bug ;) reassigning to tod, cc george.
Hi! The neglect of bugs 1819 and 9081 lies with me ;( But thanks for your showing your interest. I will use this bug as a sounding post for my thoughts on the matter. And would appreciate comments from interested users and other developers ( george?). Here is what I would like to see happen with the linear algebra packages: 1. create a virtual/blas, default F77 blas Rational: allows multiple blas implementations to be merged [F77, atlas, intel fastmath (future), other vendor supplied blas' (amd, alpha, sparc, ppc), gnu sci library] Default to be f77 because it is the reference implementation and should have fewer possible issues and is a relatively quick compile (atlas can take considerable time) for those just wanting to give an app a try. Also, for development it is desirable to have a solid reference implementation installed. Serious users can explicitly emerge their choice(s) of optimized blas' and then unmerge f77 if they wish. 2. Develop a blas-update (or blas-config) script and scheme, so that users can switch between multiple installed blas' implimentations. Analogous to opengl-update and java-config and gcc-config. This probably entails munging the installs of the different blas' to install into their own directory under /usr/lib and also munging the library names to be more explicit, i.e. /usr/lib/f77-blas/libblas-f77.a and then use link magic to /usr/lib/libblas.a 3. "blas" USE flag for applications that include a functional subset blas in their package tarball specific to thier application for users that don't want to install a full blas just to use the application. Numeric is an example, but I know their are several others. 4(a). lapack package will have optional USE=atlas, to specify whether to roll the atlas optimized functions into the lapack library. 4.(b) virtual/lapack ? I know thier exist alternate lapack implentations, i.e. clapack, gnu sci library 5. atlas ebuild will have an environmental variable such as INTERACTIVE to specify whether the user wants to do an interactive configuration of the build. Analogous to the ALSA_CARDS in media-sound/alsa-driver. Default would be "no" to not interfere with automated emerging and to build with sane defaults. 6. [Future} develop shared library functionality for linear algebra packages. Would probably necessitate making use of the 'static' use flag in relevant application ebuilds. Shared libraries would be useful to casual users of multiple sci apps, while serious crunching would probably want the libraries staically compiled into the app. Debian is a good reference for this although their diffs are about as large as the original tarballs themselves and are a pain to walk through. 7. [Wishlist] FFLAGS variable in make.conf. analogous to CFLAGS. This is quite an undertakng as it not only involves the linea algebra ebuilds, but also the application ebuids that depend on them. I would welcome feedback on this framework for the linear algebra packages as this is what I am working towards and so would rather here concerns or better ideas sooner rather than later. Of course, as always, any and all assistance is appreciated. tod
That all sounds pretty reasonable. I can't see any major flaws in that strategy and it would seem to work well for all users. The only potential issues could be with the Intel libraries - I've only used these in conjunction with the IFC and I'm not sure they sit too well with gcc. But I could be wrong as I haven't looked into this. I'm not sure the FFLAGS is that useful. My experience with compiling LAPACK has been that the optimisation flags may need tweaking to get things working as they should and these should then be set in the ebuild. I know this goes slightly against the Gentoo grain, but it's more important (given their usage) to havethe libraries functioning well. Aside from LAPACK/BLAS, are there any other packages written in Fortran?! Anyway, it all sounds good and thanks for putting the effort in to making this a well thought out implementation. If you need any help, just ask.
Some more thoughts.... Although there is a icc USE flag, there doesn't seem to be a ifc flag. This could well be useful here - someone may want to compile the LAPACK and f77 BLAS using ifc. I only mention this now, because I've also been looking at the lam-mpi and mpich ebuilds which could _really_ do with using an ifc flags if it existed. But I guess that's another bug.... Anyway, all this would lead to gentoo being a really slick platform for scientific computing, if combinations of various compilers, libraries, MPI implmentations just worked, straight out of the box. Ta!
Hi guys Looks like I finally got to this whole blas/lapac set of bugs. I'll try to do something on it this week.. Daniel: >Although there is a icc USE flag, there doesn't seem to be a ifc flag. This could >well be useful here > But I guess that's another bug.... So, why didn't you submit it ;). Anyway thats #32108, thuogh most likely to be dealt wth after everything else.. While I am on this: I noticed that recentle set of Watcom compilers went OSS-compatible. Would there be any interest in getting Watcom Fortran in and possibly integrated in "grand scheme"? George
Hello, since the problem of /usr/liblapack.a is still open, would it be possible as an interim solution to modify the depend part of the lapack ebuild to include atlas as well? DEPEND="virtual/glibc !blas? ( !atlas? ( dev-libs/atlas ) ) blas? ( app-sci/blas ) atlas? ( dev-libs/atlas )" Best Regards
Hi Raimondo. This bug has been silent for quite a while, but please take a look at #30453, it effectively "took over". There are a few submissions with updated ebuilds that should swing into the new scheme based around virtuals for blas and lapack. Right now we are sorting out the best way to organize the virtuals and controll the dependencies. Should get to the move some time shortly (but this is the major reorganization, so it takes time..). George
*** This bug has been marked as a duplicate of 30453 ***
