Re: Atlas-3.2.1
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. 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.
Of course, you can link statically, but then you're binary might not
run on all machines of the arch.
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. If I move the libraries around, it could be done with
alternatives, but I really didn't see the benefit here.
If you agree with the above explanation, you might want to close your
bug.
Adam C Powell IV <hazelsct@mit.edu> writes:
> Hello Camm,
>
> Beautiful job with the packaging! I'm having one problem though: ld is
> not following /etc/ld.so.conf when linking libraries, as it seems it's
> supposed to (as the ld manpage says it should).
>
> The full description of my problem is in bug #104201, against binutils.
> Any ideas?
>
> Thanks again, this is really a beautiful set of atlas packages you've
> put together!
>
And thank you for your fine work on Debian as well!
> 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 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: