Bug 30459 - atlas-lapack-3.4.2.ebuild
|
Bug#:
30459
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: george@gentoo.org
|
Reported By: nospam@dolney.com
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: atlas-lapack-3.4.2.ebuild
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2003-10-05 20:14 0000
|
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=19920) [details]
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.
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) [details]
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) [details]
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) [details]
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.
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
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
