Ebuilds to support multiple installs of different BLAS and LAPACK implementations have been requested, as well as support for shared libraries (bug 1819, bug 9801, bug 18756, bug 22424). I have written some ebuilds to do these things. Tod: I've used your good ideas #1-7 in bug 18756. I use BLAS and LAPACK in my work, and this setup works well for me. I particularly like the ability to switch to the reference BLAS and LAPACK if, for whatever reason, I suspect ATLAS may be giving me the wrong answers. This is an ebuild for ATLAS BLAS. I chose to separate ATLAS BLAS and LAPACK into two separate ebuilds. This seems more consistent with the Gentoo "just what you want/need" philosophy; they really are two different libraries, and ATLAS LAPACK is not even complete. One problem with this approach is that ATLAS would have to run its costly timing routines again for LAPACK, but I avoid this by storing the timing information for later use by the ATLAS LAPACK ebuild. BTW, why is atlas in dev-libs and not app-sci?
Created attachment 18820 [details] atlas-blas-3.4.2.ebuild
Created attachment 18821 [details, diff] atlas-gentoo.patch Should go in atlas-blas/files/
Created attachment 18822 [details] war Should also go in atlas-blas/files
Created attachment 18826 [details] c-ATLAS These are profiles for blas-config (see bug 30454).
Created attachment 18827 [details] c-threaded-ATLAS
Created attachment 18828 [details] f77-ATLAS
Created attachment 18829 [details] f77-threaded-ATLAS
Whew! All the ebuilds are in. Please refer to these bugs for the other stuff: atlas-blas-3.4.2.ebuild bug 30453 blas-config-1.0.0.ebuild bug 30454 atlas-lapack-3.4.2.ebuild bug 30459 lapack-config-1.0.0.ebuild bug 30460 blas-19940131-r1.ebuild bug 30462 lapack-3.0-r1.ebuild bug 30463 lapack95-3.0.ebuild bug 30465 All of these ebuilds provide shared and static libraries. Except for lapack95, I have tested that linking to them using either ifc or g77 works fine. The lapack shared library lists /usr/lib/libblas.so as a dependency, so that the user need only specify -llapack. Whichever BLAS is set up with blas-config will be pulled in at runtime. I've tested mixing and matching ATLAS and reference blas and lapack. All combinations of ATLAS/reference work fine for me. I've done the same with the lapack95 shared lib. blas and lapack are dependencies, so you can mix and match blas and lapack before/after compiling. I guess I took the liberty of using virtual/blas and virtual/lapack in the ebuilds, and an ifc USE variable. It might make sense to put a line for atlas in use.defaults, in case people USE atlas. It looks like dev-lang/R is the only ebuild that does so now. An aside rant: Gentoo is an attractive distribution for scientific computing, and x86 machines are being used more and more for research. I work in an academic research group. When I started three years ago, the group was using SUN workstations exclusively (about 20 machines). Since then, we have replaced more than half with x86 machines. The x86 machines perform better at half the cost. What the x86 architecture has lacked, for us, is fast compilers (particularly for Fortran 95), strong number cruncing libraries, and good development tools. Now Intel has released their non-commercial-use compiler, so we can run our Fortran codes. ATLAS is not too bad. Serious users can, of course, opt to buy (presumably) faster libraries from Intel. Gentoo has a strong advantage over binary distributions here. Debian has an ATLAS package, but its compiled for an "unknown" architecture, which sort of defeats the purpose. Alas, it would be nice to see development tools like gdb and ddd get better... Netlib has clapack and lapack++ packages. I don't use C/C++ for numerical stuff, but plenty of others do. Hopefully someone can contribute in that area and make Gentoo even better. I would appreciate any feedback, and don't mind doing some more work to bring these ebuilds up to snuff, if necessary. Thanks!
Created attachment 19370 [details, diff] atlas-gentoo.patch Please use this patch instead. I fixed a couple of minor bugs.
"BTW, why is atlas in dev-libs and not app-sci?" Historical reasons. The atlas ebuilds were originally created long before the :app-sci" category existed and "dev-libs" seemed the most appropriate at the time. The blas ebuilds were created after. A "sci-libs" (or some variation) category would probably be appropriate eventually. I would like to encourage you to keep up the good work that you have done. I have been swamped and have not been able to assist george as I should. I would encourage you to get in touch with george@gentoo.org about getting your work included in portage. Regards, tod
Hi Derek. Answering via bug, so that this becomes visible to anybody else involved with this or related ebuilds. Thanks for your interest and submissions! Unfortunately I am also in general swamped around now, plus on top of that got a long list of bugs reopened on me by recent bugzilla chages :(. On the bright side ;), I want to give you a heads up that I noticed your submissions, and even better, they were actually pretty close on my list of things to go about. Hopefully I'll be able to get to these ebuilds in the middle of the next week. George
Hi Derek. So I am going through this stuff now and I have one conceptual question. It is lapack related, but since this bug is a "conceptual" one, I am posting it here. Basically, as I understand, lapack is based on blas and provides some more stuff. It can be compiled against either blas or altas (with tweaks). So, what is the purpose of two packages (lapack and atlas-lapack), isn't this is what virtual/blas is intended for? Is it just to be able to have both installed simultaneously or is there something else? BTW, atlas-lapack IMHO is not a very good name, as it is lapack that gets installed. Intuitively I would expect the first name to be "main", so lapack-atlas might be beter ;). Then similarly lapack can also be named lapack-reference for "consistency" but this might confuse just as well. So this second one is just a wild suggestion which I am not even sure about :). George
Oh, another one. Why is this ebuild called atlas-blas? This is the same atlas as in dev-libs, just done slightly differently. Is this to deferentiat it from the older, non-virtualized versions or for something else? Anyway old versions will not be able to peacefully coexist with virtualized stuff (but they will be cleaned upon update), so this differentiation shoudn't be necessary. Actually, considering that there is media-libs/atlas, which is a newver, but more commonly used library (as is usual with scientific apps :)) it might be good to rename atlas to avoid confusion (and we have a policy of trying to avoid duplicate names, except that in this case the other atlas is "infringing" IIRC :)). George
Hi Derek again :) You might have noticed that I started adding stuff, but there is going to be a stall on the additions. As an explanation a few words about procedure: Since these changes are kind of gross - they require two virtuals and a new use flag, - they have to be "approved". As soon as I'll get the explanation on above questions I'll write to -dev formally proposing new virtuals and use flag. Then I will have to wait fpr a few days before proceeding for the comments (if any) to come in. Then, if approved (but I don't see why not) I'll continue with additions.. Oh, and I'll move atlas from dev-libs along the way if we decide to kepp its name, otherwise I'll first add atlas-whatever to app-sci, wait for all this stuff to be tested and then unmask new stuff, switch whatever dependencies are there on atlas and then remove it and old incarnations of lapack. Although removal might wait - its not strictly necessary. BTW, atlas-blas tested out Ok, I just had to change permissions to war (a+x) in scr_unpack - it was failing otherwise. George
George, First off, thanks for working on this for me. You are correct, blas and lapack should be considered distinct libraries. Blas is more primitive, in some sense, in the math operations it provides. The lapack routines use the blas primitives to do more interesting things. Atlas provides all of the blas routines, but (at this time) only a small subset of the lapack routines. My atlas-lapack builds a complete lapack library from the reference lapack by replacing the non-optimized reference routines with the optimized atlas routines. And so, the lapack and atlas-lapack ebuilds really make different implementations of the lapack library. It appears that atlas is under active development, so that atlas-lapack can evolve into a more completely optimized lapack as the atlas people release newer versions. A standard atlas release builds both blas and lapack. There are some tips on the atlas webpage about rolling in the missing lapack routines from the reference implementation to make a complete library. This is basically what I've done in atlas-lapack. Anyway, I decided to separate the atlas build into atlas-blas and atlas-lapack, because I can imagine there are users who don't use lapack and just want blas, or packages that may depend on blas but not lapack. They really are different libraries, and this separation seems to agree more with the Gentoo philosophy. The bottom line here is that atlas-blas gives you a blas library, and atlas-lapack gives you lapack without blas. My atlas-lapack ebuild depends on atlas-blas, only because the atlas-lapack build needs the timing information in the headers installed with atlas-blas. Now I see a minor bug in the atlas-lapack ebuild about this. I'll attach a better version. Note that the blas-config and lapack-config scripts allow mixing and matching of reference and atlas. That is, one could use atlas-lapack with blas-reference, or lapack-reference with atlas-blas. I'm not sure this mixing is very useful, but it is nice to be able to switch from atlas to reference to make sure atlas isn't just giving you the wrong answers. The reference libs should give the right answers, provided the compiler's optimizations haven't ruined something. Or, for the curious, you can time your code with the reference and with atlas. As for the naming, I agree with you that it is confusing. Most users will look for "BLAS" or "LAPACK", and probably have never heard of ATLAS. So I propose we have these packages: blas-reference, blas-atlas, lapack-reference, lapack-atlas. This way, someone looking for the libraries by name will find them, and if they care they can surely figure out what *-reference and *-atlas mean. I don't know about media-libs/atlas. I see a media-libs/atlas-c++, but the description implies it's something for role-playing games or something. There's also a games-util/atlas.
Hi Derek. Thanks for the clarification and sorry for a long delay (was waiting for approval of virtuals and got carried away by all the gentoo/non-gentoo stuff :(). I will try to finish the transition now. The proposed naming scheme makes a lot of sense and I'll go with that. I would like to first get done with the reorganization, so I'll deal with ifc (as an optional substitute for gcc) later. BTW >Now I see a minor bug in the atlas-lapack ebuild about this. I'll attach >a better version. Is the update to #30458 on 10-28-2003 the promised "better version" one? George
Another question: what option should be "default" in these virtuals? I would guess more optimized (atlas) would be preferred generally, however I can see two issues with that: 1. larger download and longer compile (blas is really quick and trivial in that sense) 2. Potential errors, as this is not *the* reference implementation. But is this really an issue? I would consider 2nd to be more important and defining. If it is safe to go with atlas by default, I think we can tolerate a larger build. While it is quite a bit more involved than blas, but its not that bad either.. Same question wrt lapack-referense vs lapack-atlas. I think it would be nice to have a corresponding default in both cases though (i.e. both -reference or both -atlas). George
Yes to your first question, except I think you meant bug 30459. At any rate, the new ebuild posted there on 10/28 is the "better version". About the default: I see this requires some thought. These is an atlas USE flag. Can virtual/blas be made to default to blas-atlas in case the atlas USE flag is set, but blas-reference if not?
Hm, I don't think so. Defaults are defined in $PORTDIR/profiles/some-profile/virtuals and the format is pretty basic: virtual/name category/pkgname Extending the functionality would require another discussion on -dev and some modifications to portage, which I would not sure be completed before portage-ng.. Plus upon the transition to the virtuals the "atlas" use flag will loose its present purpose and would normally have to go away if not for a possibility of such its use. Another possibility is to go with just use var without virtuals. This is the easiest way and requires less maintaince. Then we can just have one ebuild for lapack and it will link either against blas or against atlas, depending on that flag and we can leave the names of blas and atlas at just that. On top of that we can have an ifc use flag to regulate what fortran compiler is used. What are the advantages of virtauls approach? I can see the possibility of two versions of lapack being installed side-by-side, while with just a use flag there normally be only one version, but what about the blas library? As I understand they should be able to coexist peacefully (I mean blas and atlas), but in the absense of blas-config one would have to manually add necessary -l flags to their project. Or can we actually go without virtual/blas but with blas-config? Looking through that script I did not notice anything special in that regard.. George
Ok, revisiting #18756 and recalling that there are more implementations of blas (at least), with cblas from gsl quite functional, I think the virtuals with -config scripts is the way to go. In view of other blas implementations the "atlas" use flag is becoming questionable. However how else can we automatically select the implementation? In general two ways of handling implementation selection can be thought of: 1. "Useless" way would be to emerge all desired blas implementations, then use blas-config to set the active one and the emerge desired blas users. However this makes it at least a two step process, although easily understood for the emerge process, so it might be not that bad. However this has an issue of tracing what has been built based on what.. 2. Employ use flags, one per implementation. This seems easy on the surface, - just set appropriate use flags. But this gets worse if we start considering possibility of multiple flags being set. How do we choose the implementation to use for that particular package and how (again) do we trace what has been built with what? But this is an involved issu of itself and we do not have to deal with it immediately. Besides per-package use flags has been recently implemented if I am not mistaken, so some mechanism for tracing similar things may already be in place.. In any case the first step would be to clean-up blas and atlas ebuilds, add them to the tree, add corresponding virtual and adjust dependencies of the packages that link against blas.. George
George, I've though about this, and at last I have to agree that the virtuals approach is the best. I was starting to lean toward USE flags only, but as you rightly point out, we should make this work in some way that will be sensible if/when more blas/lapack implementations are added to the portage tree. I am inclined to think your option #1 is the way to go. Let users pick their blas/lapack with the config scripts. Still, this approach has the problem that it will not be obvious which blas/lapack packages have been built against (this being selected by the *-config scripts). But I think this is a lesser worry (at least for me). Isn't this only an issue if packages are linking to the libs statically, anyway? In theory at least, one should be able to switch the shared libraries with the *-configs without hiccups. So there are these info files that an emerge places in /var/db/pkg, I mean CONTENTS, USE, *.ebuild, etc. Can an ebuild drop its own extra info files in here in addition to the standard set? One could just put the output of blas-config -p or whatever in a file there for reference. If this is not possible, maybe it is a feature to think about for portage-ng? Just a thought. But I don't see why an ebuild's pkg_postinst() can't write more stuff to /var/db/pkg/its_group/its_pkg. Is this a bad idea? It would be up to the package maintainer to make his ebuild record this info if he is linking statically. I see that this point has much larger scope than this blas/lapack stuff. For example, who can tell me which binaries on my Gentoo system were linked to something statically, and which versions they were linked against? Have I updated those libraries since then, so that perhaps I would want to rebuild the package? We still have to decide which virtual to use as default. I vote for atlas. Most serious users of blas/lapack will agree that the reference implementations should only be used as a last resort, when optimized libs are unavailable. With atlas, we have optimized libs that are also open source! I haven't timed the builds, but I don't think the atlas total (blas+lapack) build process is that much longer than ref blas+lapack. Maybe twice as long at most, but I don't think its unreasonable.
Ok, after some more thinking I seem to converge on virtual in its simplest incarnation as well. This got to be the long message and I decided to make it a "principal" one, if the approach below gets accepted, and probably reference from other places. Peter: I added you to CC since you will be, at least indirectly, involved with this stuff, plus I saw you submitted few ebuilds that depend on blas and lapack. Therefore I would appreciate a comment from the interested person ;). Basically we have a choice of virtual and use flags as a means to control the choice of implementation. Then there is an issue of maintaining integrity (i.e. to avoid weird or broken combinations of blas "backends" used by related packages). As for your suggestion of putting some additional info into portage db of installed packages, it may indeed be quite usefull in general, however don't hold your breath on this being implemented before portage-ng. And we need to do something now, preferably compatible ideologically with such approach, to make the transition easier if this indeed gets implemented. I believe there were proposals along these lines for portage-ng, but if you can formulate this in sufficiently generic terms ("providing sufficient hooks to store and read additional info that may be used by ebuilds/installer" say) I would encourage you to submit the proposal to gentoo-portage-dev@lists.gentoo.org Lets revisit the use flags. They might nicely solve the specification of blas realisation choice during initial installation. However users potentially can change their use flags thereafter and when things get updated they will get packages linked against another blas library. This is still Ok for immediate dependants of blas, but may cause problems for more distantiated dependants. Say something depends on lapack that was originally compiled with atlas, but now user has his useflags set to "blas-reference". As such packages usually link against both lapack (or what have you) and blas here we go to a failing compilation or execution.. Unfortunately this problem cannot be cleanly solved with use flags. While portage supports per-package use flags for some time now, what we really need here is ability to depend on package that had certain use flag configuration. This is #2272. From the number you can guess this has been an issue for a loong time now and I truly don't think this will get addressed in the present branch of portage. So, what about virtuals? First it seems to be conceptually easier to extend to the case of more than two blas realisations. Second, the issue of tracing what was built agains what is still there, but we are not tied to any control mechanism. Well, all the tricks are possible with use flags as well, but then what will be their use? (funny wording here :)). Moreover with virtuals it is possible to have multiple realisations to be installed side-by-side (ebuilds might need some tweaking, but at least blas and atlas seems to be Ok in that respect) and the active one can be chosen dinamically. Now the integrity issue. The ebuilds for virtual/blas dependants will need to be modified to store the info on what blas incarnation was active at the moment. However IMHO this should not be stored under /var/db/pkg. Lets leave this for official portage info. We can use /usr/share/${PN} instead (if package is SLOTted then /usr/share/${P} or ${PN}-$SLOT perhaps). This location seems to be appropriate and we are not screwing around portage internal structures. What about use of this info? I think that running automatically blas-config from pkg_setup is a bad idea. First, messing with system environment is not gonna be wellcomed by admins and, second, this seems to be a bit against the Gentoo "approach". Instead ebuilds should perhaps simply check what blas implementation was used, check which one is active and then either carry on or stop with informative message. For immediate blas dependants this can be just a warning and some env var can be accepted to force rebuilding against presently active blas (although the same effect can be had by simply unmerging and then emerging the package, but accepting env var seems to be "cleaner"). For the distantiated dependants (e.g. that include lapack as well) is should be the genuine stop with message asking to either activate appropriate blas or to remerge lapack against presently active one (or activate corresponding lapack). This approach seems reasonably clean to me right now and require user input only where it is, well, required :). However I would appreciate some feedback on whether this long write-up makes any sense :) or if I missed something. One last thing. blasconfig and lapack-config should probably be syncronised or even merged. Is there any use in having blas set to one implementation and lapack to another? And the afterlast issue :). It looks like we do not need any use flags with such approach. Should they be eventually dumped (there is "atlas" now at least) or is ther some, perhaps not so much related use for it/them? George We can
> One last thing. blasconfig and lapack-config should probably be syncronised or > even merged. Is there any use in having blas set to one implementation and > lapack to another? Two reasons I can think of are for more control over debugging/comparison of calculation results, and possibly benchmarking purposes. For the record, I made sure that it is possible to mix and match blas and lapack implementations, regardless of why someone would want to do this. Also, we should think how a combined blas-lapack config script would work if additional implementations of blas and lapack are added. In particular, suppose there some other group that releases an optimized blas lib but no lapack lib. In such a case it is not obvious how the configure script should behave. At the least, the script would need flags to allow changing of blas and lapack separately anyway. And so, this seems to be more of an organizational issue to me. Let's think about it this way: what should the scope of the config script be? Just blas and lapack together? A config script for all scientific libraries? One could even imagine combining *all* such configs --- gcc-config, java-config, blas-config, etc. --- into some sort of "gentoo-config" beast. I like your point about using /usr/share/${PN} to store info. I didn't think of that, but it makes much more sense than my idea, especially from a consistency point of view.
Ok, blas-atlas is in, please test. I slightly redid src_install to replace mv's with "cp -P" - otherwise it screws src_install debugging (it is nice to be able to run multiple install's after just one compile.) Note to self: check if blas-config needs updating with both blas packages now renamed. I'll keep this bug open meanwhile, as it is central in terms of discussion of this reorganization. George
Ok, blas-config seems to be working and I adjusted the app-sci/xfoil (the only package that does not depend on lapack but depends on blas) to use virtual/blas. Please test the whole complex ;). The easy way to do this is to add blas-reference, blas-atlas and other involved packages into /etc/portage/package.unmask. If this tests out Ok I'll continue with lapack transition and will adjust the rest of dependants, at which point we will need more testing and then will be able to unmask everything.. George
George, I've tested the ebuild in portage, and it works fine. Two comments: 1. We refer to atlas-blas on line 38. Should change to blas-atlas. 2. RPATH is defined in src_compile(), but also used in src_install() and pkg_postinst(). I've also checked that xfoil compiles and runs with blas-reference and blas-atlas. I don't know how to use this, so the extent of my test was no more than compiling xfoil and checking that there are no runtime link errors for the xfoil executable. I didn't think of this until now: should we have separate virtuals for blas and cblas (or fblas and cblas, or whatever)? It could become an issue. For example, blas-reference does not provide cblas, so a package that wants cblas should not accept blas-reference, but as it is set up now, blas-reference provides virtual/blas and there seems to be no easy way to distinguish the languages that are being provided.
Hi Derek. Thanks for testing and catching the slips. I set about adding the lapack to portage, but first decided to retest the blas-atlas and for some reason I am getting failures now :(. I'll attach the tail (happens first thing out, right after configuration). So, I guiess, this has to be sorted out.. George
Created attachment 25639 [details] error log The promised log.
I get this error now, too. It appears to be a bug in libtool: bug 41925.
Hm, not too good, but at least its making sense now :). Anyway, I was trying the 3.6.0 version and it seems to build fine, however the patch (to gentooise it and make build shared library) has to be adapted, as it does not apply cleanly. I'll try to get at it, but probably with a slight delay.. Nathaniel: Added you to CC as you submitted #36613 and I would like to merge these bugs. Could you please take a look at the blas-atlas ebuild in portage and comment on the issues involved? The final ebuild should play along with the virtualization, which mainly means install libraries in the "designed" place and provide appropriate symlinks that are adjusted by blas-config script (yes quite a bit more involved, but this is a price to pay for the ability to mix and match..). Another thing. I see the last modification you made to your atlas ebuild checks whether lapack is installed and, if yes, uses its library. I am not sure what to make of it, as it kind of goes backwards to the dependencies. Normally we have lapack depending on blas (either reference or atlas) and such behind-the-scenes check will create a mess I am afraid (like what happens when you remove lapack later on?), - normally this kind of interrelation should be supported on a metadata level as well. In case anybody wants to take a look at the nvolved submission, these are comments 4 and 5 in #36613. George
Created attachment 25939 [details, diff] atlas3.6.0-shared-libs.patch Patch to build shared lib for atlas 3.6.0. This should be used instead of atlas-gentoo.patch for version 3.6.0. I changed the name to contain the version and be a bit more descriptive: these patches enable building of shared libs. This patch is suitable for both blas-atlas-3.6.0 and lapack-atlas-3.6.0. The ebuilds can just be renamed and they work (for me, with an older version of libtool...). I've made a very minor tweak to the lapack ebuild. I will submit it next.
Hi Derek. Thanks for updating the patch. However now it looks like it was the patch that was giving this trouble :). Specifically new version of libtool apparently does not like something. These are the first problemmatic lines: system: whoami > /tmp/fileKFn3zg system: date > /tmp/fileKFn3zg libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[3]: *** [ATL_buildinfo.o] Error 1 I have here libtool-1.5.2-r3 installed. George
Ok, Looks like I resolved this, added --tag=CC to LIBTOOL definition in the patch throughout. However now I am getting what looks like a failing test: /usr/lib/distcc/bin/gcc -DL2SIZE=524288 -I/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include -I/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/Linux_PIIISSE1 -I/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib -DAdd__ -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_PIII -DATL_SSE1 -DATL_GAS_x8632 -fomit-frame-pointer -O3 -funroll-all-loops -o xcr1 cger1tune.o \ ATL_cger.o ATL_cger1.o ATL_cger1_dummy.o /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/lib/Linux_PIIISSE1/libtstatlas.a /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/lib/Linux_PIIISSE1/libatlas.a /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/bin/Linux_PIIISSE1/ATLrun.sh /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/tune/blas/ger/Linux_PIIISSE1 xcr1 -C 2 -l 87 -m 1000 -n 1000 \ -f 16 res/cger1_2_87 : 274.459975 MFLOPS res/cger1_2_87 : 222.222222 MFLOPS res/cger1_2_87 : 169.411765 MFLOPS res/cger1_2_87 : 222.03 MFLOPS make[4]: Leaving directory `/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/tune/blas/ger/Linux_PIIISSE1' res/cger1_2_87 : VARIATION EXCEEDS TOLERENCE, RERUN WITH HIGHER REPS. BEST: ATL_ger1_SSE.c, mu=32, nu=2; at -175.00 MFLOPS make[3]: *** [res/cR1RES] Ошибка 255 make[3]: Leaving directory `/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/tune/blas/ger/Linux_PIIISSE1' make[2]: *** [/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/tune/blas/ger/Linux_PIIISSE1/res/cR1RES] Ошибка 2 make[2]: Leaving directory `/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/bin/Linux_PIIISSE1' ERROR 680 DURING R1TUNE!!. CHECK INSTALL_LOG/cR1TUNE.LOG FOR DETAILS. make[2]: Entering directory `/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/bin/Linux_PIIISSE1' cd ../.. ; make error_report arch=Linux_PIIISSE1 make[3]: Entering directory `/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS' make -f Make.top error_report arch=Linux_PIIISSE1 make[4]: Entering directory `/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS' uname -a 2>&1 >> bin/Linux_PIIISSE1/INSTALL_LOG/ERROR.LOG /usr/lib/distcc/bin/gcc -v 2>&1 >> bin/Linux_PIIISSE1/INSTALL_LOG/ERROR.LOG Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs Configured with: /var/tmp/portage/gcc-3.3.3/work/gcc-3.3.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,f77,objc,java --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-interpreter --enable-java-awt=xlib --with-x --disable-multilib Thread model: posix gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7) George
Created attachment 26448 [details] an updated patch Attaching the patch modified to pass --tag to libtool, as seems to be required by new version.
George, I am working on a new patch. I haven't had much time lately, but I should have this working in a day or two. There are more issues with the new libtool than just the --tag argument. I'm not sure --tag=CC is the way to go, as these are not C++ files. The tag option is poorly documented, but it is evidentally used to specify the language, and we have both C and F77 sources. A (seemingly) easier solution is to make the change /usr/bin/gcc -> gcc in the makefiles. Then libtool recognizes gcc and doesn't need a tag (seems libtool's become a bit fussy). Anyway, I've made this fix, and all objects compile, but libtool's linking behavior has changed, which will take a minor fix. Like I say, gimme a day or two. I have seen the "VARIATION EXCEEDS TOLERENCE, RERUN WITH HIGHER REPS" error you got. It seems that this can happen if the system is under load when atlas tries to do its timings. I just recompiled it while the system was more free. There is a note about this on the atlas website, if I remember correctly. Perhaps we should have the ebuild pop up a note before compiling? Derek
*** Bug 9081 has been marked as a duplicate of this bug. ***
*** Bug 18756 has been marked as a duplicate of this bug. ***
*** Bug 22424 has been marked as a duplicate of this bug. ***
Created attachment 26692 [details] blas-atlas-3.6.0.ebuild Trivial changes only. Attaching for definiteness.
Created attachment 26693 [details, diff] atlas3.6.0-shared-libs.patch.bz2
Created attachment 26694 [details] war
OK, George. We should be back in business, now. Please test. After a closer look at libtool, it seems I was wrong: --tag=CC appears to be for C source. There is a --tag=CXX. And I finally decided to use these tag lines as you did---seems more robust, and it was easier anyway. Note that the archive wrapper, war, had to be changed because of other differences in the new version of libtool.
*** Bug 36613 has been marked as a duplicate of this bug. ***
Ok, I am back from the conference. Thanks for an update! However it not all good yet. It now fails on the linking step, near the end of the build :(, so testing wasn't very pleasant, considering that it was failing numerous times before that, during statistics collections, if I even just touch the computer. You can guess that added to the number of trials :(. I think we should add some kind of notice in case build fails during the statistics/tests phase. Probably call the function that tells to keep system totally quiet during the build instead of plain || die... Anyway, this is what I am getting now: Linking a really big library, please be patient... cd gentoo/libatlas.a ; \ libtool --mode=link --tag=CC /usr/bin/gcc -o libatlas.la *.lo -rpath /usr/lib ; \ libtool --mode=install install -s libatlas.la /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs libtool: link: `ATL_cgemvC_b0.lo' is not a valid libtool object libtool: install: `libatlas.la' is not a valid libtool archive Try `libtool --help --mode=install' for more information. I first thought it did not like distcc (I had it on), so tried to run more tests (which were failing as above :)) with distcc disabled (it does not seem use it all that much anyway. I've got 72 vs 86 minutes with enables vs disabled distcc). Does this remind you of anything? George
Hmm. My compilations were never so sensitive to cpu load. I avoid running some other intensive job, but I can use my desktop normally for email, music, whatever. Is the atlas build less sensitive after you turn distcc off? I can imagine that distcc might distribute its timing variants to different computers, in which case the timings it sees could be wildly different, giving you the VARIATION EXCEEDS TOLERENCE, RERUN WITH HIGHER REPS error. Can we disable distcc for this ebuild? I think we should. I do not get this linking error. My /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libatlas.a/ATL_cgemvC_b0.lo is a link to /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/src/blas/gemv/Linux_ATHLON/ATL_cgemvC_b0.lo. Please check that yours is a link to a file that exists, and also have a look at the file for me. Is it a binary object or a libtool text wrapper?
>Is the atlas build less sensitive after you turn distcc off? Didn't look like that, - I had it fail twice with EXCEEDED TOLERANCE... that time, once with distcc, another without.. I guess it also depends on the hardware - I am running this now on P-III 700 (did not update my hw in a while, but I see I need it now :)), so every test takes upwards of an hour, not very pleasant when I have to run many of them :(. But yes, I think it makes sense to disable distcc for this package. The best would be if there was RESTRICT=nodistcc "goal" supported, but I am not so sure. I'll check on that. I've rerun the tests, same complaint, but now it fails on libtool --mode=link --tag=CC /usr/bin/gcc -o libatlas.la *.lo -rpath /usr/lib ; \ libtool install -s libatlas.la /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs libtool: link: `ATL_dgemvN_b0.lo' is not a valid libtool object dgemvNm instead of cgemvC, one major letter further, so I guess this is more on a good side :). And yea, I have that link pointing to the same location (as well as all the others) so the difference is elsewhere. I wonder if this may have anything to do with me mounting /var/tmp/portage on tmpfs? I'll run another test on a "regular" partition, so hang on for another update :). George
Still getting the same :(. The file on which it dies is different most of the time, but only varies slightly. And the link points to the existing file, which also seems to be quite reasonable of itself: libtool --mode=link --tag=CC /usr/lib/distcc/bin/gcc -o libatlas.la *.lo -rpath /usr/lib ; \ libtool --mode=install install -s libatlas.la /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs libtool: link: `ATL_cgemvC_b0.lo' is not a valid libtool object libtool: install: `libatlas.la' is not a valid libtool archive then groug gentoo # ll ./libatlas.a/ATL_cgemvC_b0.lo lrwxrwxrwx 1 portage portage 90 Мар 13 15:15 ./libatlas.a/ATL_cgemvC_b0.lo -> /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/src/blas/gemv/Linux_PIIISSE1/ATL_cgemvC_b0.lo and groug Linux_PIIISSE1 # file ATL_cgemvC_b0.o ATL_cgemvC_b0.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped . I also tried it on a different system (Athlon XP-M) and there it gets locked after collecting system info: [...] IN STAGE 1 INSTALL: SYSTEM PROBE/AUX COMPILE [...] system: /usr/i686-pc-linux-gnu/gcc-bin/3.3/g77 --version > /tmp/file44svB7 system: uname -a > /tmp/file44svB7 system: whoami > /tmp/file44svB7 system: date > /tmp/file44svB7 Waiting for ATL_buildinfo.o.lock to be removed Waiting for ATL_buildinfo.o.lock to be removed ... and here it just goes on, without visible end to it (I waited for 30 min). George
Created attachment 27708 [details] atlas3.6.0-shared-libs.patch.bz2 George --- I found the reason for your "libtool: link: `ATL_cgemvC_b0.lo' is not a valid libtool object" error Please test this new patch. It should fix the build.
Hi Derek. Thanks a lot for the update. And sorry for the disappearance - I got it tested few days ago, but before I had a chance to prep the dir and commit HDD on my laptop decided to crash :(. Being in the "travel mode" it took a bit longer to recover, but I am getting back now :). Anyway, just wanted to leave a note, that it seems I was able to test it out Ok and that I'll try to act on this soon.. George
That's OK. I also got busy with paid activities and couldn't work on this for a bit. I tried this on an Athlon XP and did not have the "waiting for ATL_buildinfo.o.lock to be removed" problem. Can you try this again on that machine? That's very strange. Were you using distcc or ccache or anything that might interfere? Derek
Ok, the 3.6.0 is in portage, please test. However now I am getting the same libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' when testing blas-reference. I guess this time we need to add --tag=F77. Did you add anything alse when updating that patch for blas-atlas? I'll try to look at the lapack ebuilds now.. George
Ok, I got it, added a few --tag=F77 to Makefile and recompressed it with gzip (it actually produces smaller files when they are small, not that it matters for a few-k file and a few bytes of difference :)). In portage (no revision bump, since this is a compile-time fix), please test. George
Few thoughts on the transition to the new blas/lapack scheme: Apparently it is taking quite some time, so rather than to do it in one large sweep I am thinking about doing it in stages: 1. blas-* gets committed (seems to be done) and tested 2. blas-* are moved into ~arch (from package.mask), announcement is made (again) about the new organization of blas/lapack world. Maintainers of blas/lapack dependent packages are encouraged to start updating their packages to work with new scheme. Meanwhile old blas/atlas ebuilds are still in the tree; work on lapack is done. 3. lapack-* are committed and is being tested (this also includes appropriate virtuals) 4. upon tersting these also get moved to ~arch and another announcement is made. 5. All the dependants are being taken care of. 6. old blas/atlas/lapack ebuilds are hardmasked and some more time later removed from the tree. George
George, OK. I have tested blas-atlas on three machines (p3, athlon-xp, athlon-tbird) and everything seems to work. Thanks for adding tag lines to blas-reference. You are right, that is the only change it should need for the new libtool. I have tested the blas-reference you put in portage and it works for me. There is an annoying issue we should think about: older versions of libtool do not understand the --tag=* arg, and will fail if given it. At the moment, libtool-1.5 versions are marked unstable. I guess the easy/lazy way is to leave all of this blas/lapack unstable until a libtool-1.5 goes stable. The alternative is to have two patch versions (just strip out all the --tag=* args) and ebuilds that are slightly smarter about putting in --tag=* or not, depending on the libtool version.
*** Bug 50586 has been marked as a duplicate of this bug. ***
I marked both blas-config and blas-atlas ~amd64 and ~ppc. Had no time to test blas-reference yet, but I will try today...
George, I have tested to install blas-atlas-3.6.0 with gcc compiled without support for fortan (as we discussed in bug #50586). It did not work actually. It hangs in a while-loop with this printout: F77 = 'g77 -fomit-frame-pointer -O' doesn't seem to work for me. Enter 1 to enter a different F77, 0 to continue with none [1]: I'm going to ask you for information about your Fortran 77 compiler. ATLAS does not need Fortran77 to build, so if you don't have a Fortran compiler, the install can still be completed successfully. However, ATLAS built without a Fortran compiler will not be callable from Fortran (i.e., the user should use the C interface), and we will not be able to do full testing, since some of the tester code is written in Fortran77. I.e. it prints this message over and over again, so I can't enter any answer to the question.
*** Bug 50750 has been marked as a duplicate of this bug. ***
Ookey, I think all the pieces are finally in place and I will go about unmasking the blas-* packages in a day or two, unless I get a probelm report. I just added the g77 check (pkg_setup function) to both blas-reference and blas-atlas, plus I moved atlas3.6.0-shared-libs.patch.bz2 to the mirrors (its added to the SRC_URI now correspondingly) and retested both things.. George
Created attachment 31686 [details] blas-atlas-3.6.0.ebuild George, use ifc is not enough for this build. config will still loop endlessly asking for g77.
George, By the way, I fixed a typo: the use flag for gcc is "f77". The pkg_setup message in blas-reference needs to be fixed, too.
Created attachment 31691 [details] blas-atlas-3.6.0.ebuild Oops, I wrote my name in there when I was testing something and forgot to remove it!
*** Bug 53391 has been marked as a duplicate of this bug. ***
Created attachment 33019 [details, diff] patch to blas-atlas-3.6.0.ebuild I made a patch to the ebuild to make sure that emerging blas-atlas does not go into an infinite loop when building with gcc compiled without f77-USE-flag (so g77 is not present) and the ifc-USE-flag is switched on. The emerge does not finish completely however, libtool complains about `libblas.la is not a valid libtool archive'. Do you have the same error when compiling with g77?
*** Bug 51344 has been marked as a duplicate of this bug. ***
Some packages (like octave) will test for the optimized atlas versions of the blas/lapack libraries and use them if they are found. But why is there a dev-libs/atlas and also an app-sci/blas-atlas and an app-sci/lapack-atlas? I understand the gentooish reason for having two specific atlases, but why then have the regular atlas at all? Its not clear whether one can get the octave improvements by just using dev-libs/atlas, or whether one has to run the app-aci atlases, or ... both?
The reason is that we are right at the transition at this point. The simple atlas and lapack packages are old ones, no longer supported but still necessary untill all the packages in the tree transition to new blas-* and lapack-* alternatives. Actually this should have happened already, I sent like 3rd mesage requesting package maintainers to do this change before going to my last trip, but looks like nothig have happened :(. I guess I'll have to attend to this myself.. Oh, well, I am back now, so I'll try to see to it in a few days. Meanwhile please bear with us. To summarize above long discussion and answer your question: new packages blas-* and lapack-* that are under app-sci are supposed to be used from now on. Old versions, not under app-sci and having simple atlas/lapack names are deprecated and will soon (hopefully) be removed. Thats the short story, for the long one you are wellcome to read all above comments ;). George
Current version in portage is blas-atlas-3.7.10, I have no idea why this bug is still open. Closing as FIXED.
Argh, and I was looking for it. The reason this bug remained open is that this is a tracker-bug and the transition to a new blas/lapack subsystem is not complete yet. I'll try to change the summary filed to reflect the real role of this bug, and reopen it. Lets hope it will stay in site now :). George
Hi, I had a problem with the autoconfig of blas-atlas on my laptop. See bug 102088 . I'll take a closer look at it after my vacation. (end of august)
(In reply to comment #69) > Argh, and I was looking for it. > The reason this bug remained open is that this is a tracker-bug and the > transition to a new blas/lapack subsystem is not complete yet. Heh, sorry for closing then, at least you found it now. :)
OK, as far as I can see all packages which require lapack/blas now use the new infrastructure in ~arch. So I guess the next steps are: * Danny converts lapack-atlas and friends to the eselect infrastructure * two weeks stabilisation * marking these libraries stable * marking the new versions of the software which uses lapack/blas as stable * removing the old versions (I guess this is not so urgent)
(Forgive me if this comment should be a new bug or go somewhere else, please inform me and forward appropriately.) I just updated my various lapack things and they broke scipy, because my blas and atlas config settings were changed to "XXX reference" by emerge. I am resetting them now and will recompile, but this resetting of them seems like a Bad Thing Here is the bug I filed the last time this happened to me for reference: http://bugs.gentoo.org/show_bug.cgi?id=129524
Stale dead bug.
