Re: Atlas-3.2.1
Camm Maguire wrote:
Hi Adam!
Adam C Powell IV <hazelsct@mit.edu> writes:
Hmm, revisiting that manpage, I suppose it's a matter of interpretation:
"The linker uses the following search paths to locate required shared
libraries." In the context of an ld manpage, this says to me that these
search paths are used at compile time. But if what you're saying is
correct, then it should be clarified so it's obvious that it refers to
runtime.
Yep. I think 'rpath' = "runtime path".
Oh yeah. My bad. :-)
Please note that if you develop something which
dynamically links against atlas, whichever lib you use at compile time
will be overridden at runtime depending on the users setup, so you
might as well use atlas2-base-dev, and avoid adding another -L to the
link command line. But it doesn't matter, its your choice. If you're
developing something that just uses the blas or lapack interfaces,
you'd be best off compiling against blas1-dev or lapack-dev -- these
are still more portable, and your users will still transparently get
the speedup by installing atlas if you link dynamically. In either
case, you need a shlibs.local file in debian/ like 'libblas 2 blas2'
or 'liblapack_atlas 2 atlas2', a line for each lib you use, so that
you're package will depend on the virtual packages atlas2,blas2,and/or
lapack2 and will be satisfied with any of the providing packages, and
not insist on the one upon which you build-depend. I should probably
put a development section in the README.Debian.
I think the shlibs dependencies are automatically generated for binary
executable packages by dh_makeshlibdeps, which (AFAIK) uses ldd and dpkg
-S and the packages' .shlibs files, so all that matters is that .shlibs
file for the library packages...
Speaking of which, I just noticed that
/var/lib/dpkg/info/atlas2-p3.shlibs has atlas2-p3 as the package
containing the libs. The result of this is that any package built
against atlas2-p3 will depend on atlas2-p3. Is this really what you
want? I think you would want it to depend on atlas2, which can be
provided by atlas2-p3 or any of the other binary-compatible
alternatives, right?
Yep, you are right that this is the default behavior. To take
advantage of the Atlas structure, *packages* depending on the atlas
libs need the following in debian/shlibs.local
libatlas 2 atlas2
liblapack_atlas 2 atlas2
libcblas 2 atlas2
libf77blas 2 atlas2
Right, but shlibs.local is (can be) automatically generated from the
shlibs files of the shared lib packages themselves. For example, when I
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
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.
Makes sense now?
Note that a feature of this automatic shlib dependency generation is
that on arches which need lapack instead of atlas, the lapack2 (or
whatever) dependency is automatically generated, so I don't need to
customize this section of the petscgraphics package. In fact, because
it just Build-Depends on petscgraphics2.1.0-dev (it doesn't directly
link anything else), which Depends on the appropriate local linear
algebra implementation (lapack-dev, atlas-dev, or even cxml on alpha
systems where PETSc is built using the Compaq compilers and libs), the
linear algebra dependencies are automatically dragged in from PETSc
without having to think about them at all in petscgraphics! And the
less I have to think about, the happier I am.
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.
atlas-dev may not exist any more, but it's the only common Provides:
among your atlas2-*-dev packages, so I changed atlas2-dev to atlas-dev.
If your packages provide atlas2-dev, then I'll change it back, so
nobody tries to build PETSc against ancient atlases. :-)
Then again, would building against ancient atlases be a problem?
I thought about a virtual development package atlas2-dev, but then
only one of these could be installed at a time, as someone would need
to own /usr/lib/libatlas.{so,a}, even if a link, for it to be
transparent.
Hmm, why can't they all just provide atlas2-dev? I think I'm missing
something. As long as the user sets LIBRARY_PATH appropriately at
compile time, it should "just work", right?
Well, I don't know if this is policy or anything, but I thought that
the idea behind a virtual package is that everything should work
unchanged if any one of the providers is installed. So in this case,
this is not transparent as the user would have to set LIBRARY_PATH or
-L on link command line depending on which -dev was installed. It
will work, but not transparently. Does this merit a virtual package?
See above; it's your call, but if the new atlas packages are not
source-compatible with the old ones (pre-atlas2-dev), then I think it
would merit a new virtual package.
OK. Thanks for your work on Debian! BTW, what are you developing
that depends on atlas?
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.
With regard to PPC, yes, I'm a PPC user, but not Altivec (yet?), just a
160 MHz 603e I've used as my home machine since getting it for $500
three years ago. I think the really big Altivec gains come in
single-precision, where it gets 2 Flops/clock sustained- as good as
alpha! But unlike alpha, for double-precision, it doesn't have the
bandwidth for that, even to cache. (I'm not positive about that, any
other PPC folk here?) If it did, I'd probably make a Beowulf out of
G4s, maybe even Cubes from ebay since they're low-power and fanless. :-)
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. :-)
Thanks again,
--
-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>
Reply to: