Re: Atlas-3.2.1
Hi Adam!
Adam C Powell IV <hazelsct@mit.edu> writes:
> Camm Maguire wrote:
>
> >Hi Adam!
> >
> >OK, I think your system is working correctly, but there may be a small
> >misunderstanding. The virtual atlas2,blas2,lapack2 packages provided
> >by the atlas packages, LD_LIBRARY_PATH, /etc/ld.so.conf -- all these
> >refer to *runtime* and not compile time. In other works, if you have
> >a binary which dynamically links against any atlas lib, or libblas, or
> >liblapack, you can govern which library is used *at runtime* via
> >/etc/ld.so.conf and LD_LIBRARY_PATH. All the atlas packages provide
> >all the atlas libs plus blas and lapack libs, and setup the
> >/etc/ld.so.conf to use the best installed one that will run on the
> >users machine by default. You can override with LD_LIBRARY_PATH on
> >the command line. In general, this is transparent to the user -- just
> >install atlas, and stuff gets faster, without a recompile.
> >
> >Now if you are developing, and want to specifically use a given set of
> >development libs, you need LIBRARY_PATH or -L on the gcc link line.
> >gcc does not use ld.so to link in libraries, to my knowledge. ld is
> >different from ld.so.
> >
> Right... so why does the ld manpage give that list including
> LD_LIBRARY_PATH and /etc/ld.so.conf (in the -rpath-link option)? The
> bug indicates that either the behavior or the documentation is broken.
> From what you're saying, sounds like it's the documentation.
>
> 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".
> So, amend my previous statement accordingly. :-)
>
> >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
(Actually, only the lines you use in the link are required). Then,
any package which provides the virtual atlas2 will suffice.
Similarly, if you are just linking against lapack, debian/shlibs.local
needs
liblapack 2 lapack2
which is a virtual package provided by the atlas binaries and lapack.
Likewise
libblas 2 blas2
for the virtual blas2 package provided by reference blas1 and the
atlas packages.
( I believe octave2.1, and R, are in the process of making use of the
blas2 virtual package. You should be aware of one outstanding issue,
though. Currently, the woody ldconfig has what appears to be a bug,
making it behave differently from the potato ldconfig and the specs in
the manpage, namely it searches /lib and /usr/lib before, not after,
the dirs specified in /etc/ld.so.conf when building the cache. We
have filed a bug, with a patch, and hope to have this applied soon.)
>
> 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.
> >Of course, you can link statically, but then you're binary might not
> >run on all machines of the arch.
> >
> Right; this is also the effect of putting atlas2-p3 into your shlibs
> file instead of atlas2.
>
Yep. See above.
> >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?
> Or you could can the subarch-specific -dev packages, so everyone builds
> against -base, and runtime linking happens according to /etc/ld.so.conf.
> But then people can't statically link against the subarch-specific .a
> files... :-( Is this what you meant above by "owning" the .a file? The
> .so file's ownership seems irrelevant, as long as it links to something
> with the right soname.
Yes, I think we should give people the option of the static library.
So if they are not to conflict, then they must be in different dirs,
or have different names, all of which makes the usage "not
transparent". On the other hand, if they do conflict/replace, so that
only one -dev can be installed at a time, then they *could* provide a
transparent virtual -dev package/interface, as
/usr/lib/lib{atlas,...}.{a,so} would be owned by the unique version
installed, and all would compile with the same environment, flags, and
command line no matter which *one* version was installed. This is
equally viable, in my opinion. Do you think this latter is better
than the former? The former is the strategy at present.
And to use the .so link, it, like the .a file, must be either in the
default lib path, or in LIBRARY_PATH, or in -L, etc, regardless of
what it points to. So making its usage transparent is also a source
of conflict between the packages.
>
> >If I move the libraries around, it could be done with
> >alternatives, but I really didn't see the benefit here.
> >
> I agree.
>
> >If you agree with the above explanation, you might want to close your
> >bug.
> >
> If the docs are updated... Though I suppose it becomes a nitpick at
> this point. :-)
>
OK. Thanks for your work on Debian! BTW, what are you developing
that depends on atlas?
Take care,
> 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>
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-beowulf-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: