Re: Atlas-3.2.1
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.
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?
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?
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.
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?
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.
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. :-)
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: