Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
This is an ebuild for ATLAS LAPACK. Please see comments in bug 30453. This builds a complete LAPACK library by taking routines that ATLAS doesn't provide from the reference implementation on netlib.
Created an attachment (id=18832) [edit] atlas-lapack-3.4.2.ebuild
Created an attachment (id=18833) [edit] atlas-gentoo.patch Note: this is the same patch as that for atlas-blas (bug 30453).
Created an attachment (id=18834) [edit] lapack-20020531-20021004.patch The ebuild expects this to be bzip2'ed in files/
Created an attachment (id=18835) [edit] lapack-gentoo.patch Those last two patches are for the netlib reference LAPACK.
Created an attachment (id=18836) [edit] war
BTW, the patches in lapack-20020531-20021004.patch are minor patches from http://www.netlib.org/lapack/release_notes.html that have not been put in the release tarball.
Created an attachment (id=18839) [edit] f77-ATLAS LAPACK profile for use by lapack-config (bug 30460).
Created an attachment (id=18980) [edit] atlas-lapack-3.4.2.ebuild This ebuild is a little better. I added support for ifc USE to compile the reference LAPACK routines with ifc.
Created an attachment (id=19371) [edit] atlas-gentoo.patch Please use this patch instead. I fixed a couple of minor bugs.
Created an attachment (id=19920) [edit] atlas-lapack-3.4.2.ebuild I changed the RDEPEND from atlas-blas to virtual/blas. This works, but I'm worried that a clean or depclean might yank app-sci/atlas-blas if app-sci/blas-reference is installed. This is probably not what the user will want to happen. How are does this (virtual) work exactly? Can the atlas USE flag be setup to make atlas-blas the preferred virtual/blas?
I think that there should be only one atlas package which installs both the blas and the complete lapack implementation and thus providing "virtual/blas" and "virtual/lapack". In that way you prevent problems like having the 'wrong' blas installed (because also app/sci/blas can be used). To me this seems the best solution.
*** Bug 38722 has been marked as a duplicate of this bug. ***
Hi guys. Derek: >This works, but I'm worried that a clean or depclean might yank >app-sci/atlas-blas if app-sci/blas-reference is installed. This shouldn't happen. Individual installed packages are registered in the world file, so they will be both maintained and kept track of. Dirk: I am not quite sure what you are suggesting. Is that to make one ebuild install two packages? I see a great potential for confusion here. At most we can go with the wrapper packaged (that only depends on other packages), like is done with kde ebuilds, but it is usefull to keep individual packages available as well. As for the wrong version being selected - Derek proposed a nice naming scheme that will probably be implemented if we go with virtuals approach. However there is also an issue of virtuals vs useflags on which I am not completely clear (i.e. what will work better). Please see #30453, last comments, for more details. George
Created an attachment (id=24952) [edit] lapack-atlas-3.4.2.ebuild changed some references to "atlas-lapack" -> "lapack-atlas" moved RPATH definition added -lg2c dependency to ifc built library, because the atlas portion is still compiled with gcc.
Created an attachment (id=25940) [edit] lapack-atlas-3.6.0.ebuild I marked lapack-atlas-3.4.2.ebuild as obsolete because you can use this ebuild instead, suitably renamed, of course. You can diff them and see that I just moved ${FFLAGS} ahead of -shared in the ifc link line in order to override any flag a user might set that contradicts -shared. It seemed that this was unlikely, yet possible.
Created an attachment (id=26697) [edit] lapack-atlas-3.6.0.ebuild Please test. George: this ebuild won't work with ifc and libtool older than 1.5, but these libtools are marked unstable. For now, I'm going to cross my fingers and hope that libtool-1.5 becomes stable before this package. If need be, I can add support for older libtools later.
Created an attachment (id=26698) [edit] atlas3.6.0-shared-libs.patch.bz2
Created an attachment (id=26699) [edit] war
Ok, trying to get this one done. I slightly modified the ebuild, - to set exec permissions on war (as in blas-atlas), using the atlas patch that is now in tree (IIRC it had some more modifications on top of the one posted here.) Still geting the: gcc -I/usr/include/atlas -DL2SIZE=524288 -I/var/tmp/portage/lapack-atlas-3.6.0/work/ATLAS/include -I/var/tmp/portage/lapack-atlas-3.6.0/work/ATLAS/include/Linux_PIIISSE1 -I/var/tmp/portage/lapack-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 -c -DDREAL ../f77wrap/ATL_f77wrap_trtri.c -o ATL_f77wrap_dtrtri.o >/dev/null 2>&1 libtool --mode=compile g77 -o dgesv.o -c -fomit-frame-pointer -O ../dgesv.f libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' problem. Looks like lapack-specific patch (or its Makefile) need to be updated for new libtool as well. Oh, btw, I was rebuilding the system anew after the HDD failure on my laptop and, apparently, I forgot the f77 flag to gcc, which gave me gcc without fortran compiler. As you can imagine, this does not help to build lapack :). It would be nice to track this dependency, but to do this cleanely we need to get #2272 implemented first :(. Meanwhile it is possible to do a check in pkg_setup and abort with informative message if requested fortran ompiler is not installed. George
George, This works for me. Please check that you are using the newest ebuild that I posted on the bug page. You should have a --tag=F77 in the ebuild. f77 is a new use flag starting with gcc-3.3.3-r2. I also had g77 disappear from under me, so to speak, after upgrading gcc. That's ok, I always thought gcc should have use flags for the different languages. I bet more than 90% of gentoo users don't have any need for g77. And I don't use objc or gcj.
*** Bug 50585 has been marked as a duplicate of this bug. ***
Ok, I figured that out. That damn firefox seems to have switched to autosave of links at some update and I just checked that it does so to the right dir at the time (I mostly use it for bugzilla anyway). But in its quest to ask absolutely no questions even if file with the same name already exists it just increments the first number it encounters in the file name. So I got stuff like lapack-atlas-3.6.0.ebuild but then also lapack-atlas-4.6.0.ebuild and even 5.6.0 :). I was going like "huh, WTF is that?? When did we get 5.6.0 out?" I guess I'll have to switch back to konqueror now :), if only kde guys would fix that formatting problem (whole paragraph in one line)... No matter, I've got it right now :), tested out fine and committed. I also aded a check for the missing g77 in pkg_setup, so it should solve #50585. Testing is most definitely wellcome! Now I am going to go back to bals-* packages and start unmasking them (into ~arch) following the plan outlined in #30453, so you should await an announcement on -dev in a few days. The "fix" for g77 will have to be added too whereever it is not yet in. Also I want to reduce duplication between packages somewhat (so atlas3.6.0 patch will go onto the mirrors, although war seems to be too small for that, so it'll stay in $FILESDIR) and move large stuff onto the mirrors as well. The last one actually goes for lapack-atlas, I mean here the lapack-20020531-20021004.patch.bz2, which is almost 60k. George
Created an attachment (id=31687) [edit] lapack-atlas-3.6.0.ebuild George, Presently this build also needs g77. I added a comment to try to clarify.
Hi Derek. Thanks for catching this check!. I updated ebuild andcommitted the change. Btw, [ "`use doc`" ]; syntaxis was "officially deprecated" as per recent discussion on -dev. Although this has already been "fixed" by agriffis few days ago already :). So, what's the general feel about this one? Can we un-[hard]mask it already? I ahve a request for this as some other package wants to use it... (#53031) Another thing: I've got an amd64 laptop recently, so I am testing stuff ouf on that as well :). I would add ~amd64 to lapack-atlas and blas-reference as well, but I am not sure what to do on ifc front. Its a binary compiler after all, but I read somewhere that you can link amd64 and x86 binaries together. Anybody reading this knows more details by chance? Is it even worth looking into? George
George, Thanks for the use syntax tip. I went and read that thread. I think we are ready to un-mask. Let's go for it! I have no experience with amd64, so I can't comment, except that the ifc ebuilds are not flagged for amd64 anyway. But all of these ebuilds (except lapack95) should work on amd64, as long as the user doesn't try to use ifc. Seems portage would complain that ifc blocks on amd64, so maybe we don't even need any extra tests in the ebuilds. I think it's definitely worth trying, because ATLAS at least recognizes amd64. Presumably it does something extra-magical for that arch, but I don't know any details. I'm still living in the past (x86). :(
Ok, just unmasked lapack-config and lapack-atlas. Added ~amd64 to both as well (this needed "masking" ifc useflag in use.mask in amd64 profiles). Moving on to the rest of lapack ebuilds (2 to go as I can see). George
