Camm Maguire wrote:
>Hi Adam!
>
>Adam C Powell IV <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> writes:
>
>>build petscgraphics-demo which has a binary executable linking lots of
>>shlibs, I don't specify any of the shlib dependencies in the binary
>>package's Depends: field (they have to go in the Build-Depends:, but
>>that's another matter). The dh_makeshlibdeps in the binary-arch target
>>of debian/rules automatically uses ldd and other utilities to generate
>>shlibs.local automatically. It then puts the result in
>>
>
>All this i right, except that shlibs.local is never made, rather the
>shlibs files in /var/lib.dpkg.info are consulted.
>
Right, I stand corrected.
>>petscgraphics-demo.substvars, and is automagically included when
>>${shlibs:Depends} in debian/control is interpreted, putting the result
>>in debian/petscgraphics-demo/DEBIAN/control. Right?
>>
>>So, if I build petscgraphics with atlas2-p3-dev installed, it links to
>>soname /usr/lib/xmm/libatlas.so.2 and friends which are provided by
>>atlas2-p3, and /var/lib/dpkg/info/atlas2-p3.shlibs is consulted, which
>>says libatlas 2 is provided by atlas2-p3. So that is put in the
>>dependency, and petscgraphics-demo will depend on atlas2-p3. This is a
>>big problem for everybody without a p3.
>>
>>However, if you change atlas2-p3 to atlas2 in your atlas2-p3.shlibs
>>file, then petscgraphics-demo will depend on atlas2, and the user can
>>have any flavor installed which provides atlas2.
>>
>You know, I thought this was against policy, but I just reread, and it
>doesn't seem so. And certainly makes things easier for people
>depending on atlas. So I just implemented in -9, which should be
>uploaded sometime tomorrow :-)! Please check it out.
>
Cool, will do. Thanks very much!
>>>As for portability, what I do is to Build-Depends: atlas-dev [!powerpc],
>>>lapack-dev [powerpc]. Hmm, maybe atlas-dev | lapack-dev would be better?
>>>
>>>
>>>What you have above will certainly work (outside of the fact that
>>>atlas-dev doesn't exist anymore...). But if you have shlibs.local as
>>>above, and dynamically link, then you can just Build-depend on
>>>lapack-dev, which I think should be available everywhere, and your
>>>users can still get the speedup by installing atlas. Your choice.
>>>
>>I don't think so. If I Build-Depend on lapack-dev, then packages will
>>be built with -llapack and -lblas, but without -latlas, -lcblas, etc.,
>>so installing atlas won't do anything to speed up the resulting binaries.
>>
>O contraire (sp?)! That's the beauty of this, IMHO. You *can* link
>just with -lblas and -llapack, and installing atlas will provide
>optimized versions of those libs, speeding things up without a
>recompile. And, as earlier indicated, these may be available for more
>platforms given atlas' size. Ocate, and I believe R, are already in
>the process of using this feature. Check the file-list of the atlas
>packages.
>
Really? Then what's the advantage of linking -llapack_atlas -lcblas etc.?
I'll switch the Build-Depends to atlas2-base-dev.
>>Lots of PDE stuff, centered around finite difference, finite element and
>>boundary element (which gains a LOT from atlas because of the dense
>>matrices), and some graphics, pretty much all PETSc-based. (I'm not
>>sure the graphics will use atlas, depends on how low-level we have to
>>program that part for good speed.) So most of this is an issue for our
>>group based on the PETSc dependencies.
>>
>Neat. Wish I knew graphics.
>
So far, using Geomview, it has been a breeze. The next step,
distributed rendering, will take a lot of work though.
>>So I think G4 users would appreciate an altivec-optimized atlas. And us
>>alpha users would appreciate ev5 and ev6 versions too... as your time
>>permits. :-)
>>
>In general, I was planning on building special versions only in the
>case that cpu extensions were used, i.e. meaning that a given lib
>would not run at all on certain machines of the arch. For the libs
>whichi use the common generic arch supported code, my hope was to use
>the build on the fastest reasonable representative for the standard,
>as most people wanting to use atlas would have this type of hardware
>anyway. Don't know where ev5/6 falls here. Can all ev6 code run on
>the ev5?
>
I was under the impression that Kazushige Goto's alpha assembler BLAS
were included in ATLAS. If so, there are two versions: ev4-56 and ev6,
the former I think is optimized for ev5 but the latter does not run on
pre-ev6 CPUs since it uses things like hardware sqrt instructions. I
don't think the ev6-optimized version is that much faster except for
Cholesky decomposition which uses sqrt (dtrmm?).
Thank you again, these are terrific packages!
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
