[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gfortran-4.3 the default gfortran compiler, blas and lapack uploaded to unstable

Hi Matthias,

thanks for your detailed answer!

Matthias Klose wrote:
> Kevin B. McCarty writes:

>> 1) Build-Dependencies: Packages needing liblapack and libblas to build
>> should Build-Depend on "gfortran (>= 4:4.3), libblas-dev |
>> libatlas-base-dev | libblas-3gf.so, liblapack-dev | libatlas-base-dev |
>> liblapack-3gf.so"
> In the past, there was a build dependency on the libblas-dev and
> liblapack-dev only; what is the rationale for this change?

This was just to let people build the packages if they have ATLAS
installed on their workstation instead of BLAS/LAPACK.  If you think it
is not important (and you are probably right, what with pbuilder etc.
making clean local builds easy), I agree that this simpler form is better:

>> Build-Depends: gfortran (>= 4:4.3), libblas-dev, liblapack-dev

Regarding the question of whether users will want ATLAS or BLAS/LAPACK
installed as the default choice:

>> 2) libdevel dependencies: Users will most likely prefer to have ATLAS
>> packages installed by default [1].  Hence libdevel packages needing
>> liblapack.so and libblas.so should Depend on "libatlas-base-dev |
>> libblas-dev | libblas-3gf.so, libatlas-base-dev | liblapack-dev |
>> liblapack-3gf.so"
> Is this really wanted? the libblas3gf and liblapack3gf shlibs files
> currently don't recommend atlas as the first choice.
>> [1] http://lists.debian.org/debian-toolchain/2007/11/msg00003.html

... it seems that Camm feels most users would rather have ATLAS, because
it's in general better-optimized, even though larger.

>> And should
>> there be a warning to users somewhere, that the liblapack.so provided by
>> ATLAS is in a non-default directory, so they will either need to pass a
>> -L flag to the compiler, or to explicitly link against the
>> "alternatives" symlinks, -llapack-3gf -lblas-3gf ?
> (didn't look, but this is only the case for builds using atlas?)

Correct, liblapack-dev and libblas-dev just put liblapack.so and
libblas.so into /usr/lib.  On the other hand, ATLAS puts them into
/usr/lib/atlas, in order to permit parallel installation of the libdevel
packages.  Then the files /usr/lib/liblapack-3gf.so and
/usr/lib/libblas-3gf.so are managed via the alternatives mechanism.

But most package build systems are just going to search for plain
liblapack.so and libblas.so, and probably would not know by default to
have the compiler look in /usr/lib/atlas as well as /usr/lib, nor to try
to use the -3gf suffixed .so symlinks.

So this is a crucial point: If only libatlas-base-dev is installed,
trying to link against -llapack -lblas does not work unless the build
system or the user takes special measures.  I think this is a problem if
the libdevel ATLAS package is installed in preference to the reference
implementations libblas-dev, liblapack-dev.

Camm, what do you think of this?  I know your feeling is that users
should by default get ATLAS runtime libs instead of BLAS/LAPACK through
shlibs dependencies.  But what do you feel about the libdevel packages,
given the above point?  As far as I know there isn't an easy way to make
the compiler look in /usr/lib/atlas by default when -llapack -lblas are
passed to ld.  (This is unlike the runtime library case, where you just
drop a file into /etc/ld.so.conf.d/)

Here is a crazy idea: what about having the libdevel symlinks
/usr/lib/libblas.so and /usr/lib/liblapack.so (and /usr/lib/libblas.a
etc.) themselves be managed via alternatives?  Symlinks for the
reference implementations, and their actual static libraries, could be
put in a directory /usr/lib/netlib/ (or such) if desired.  The main
downside I can see is that a transition from the current situation to
this state of affairs could be quite finicky.

>> 4) Parallel installability: New gfortran-based blas/lapack/atlas runtime
>> library packages entering Sid may now be installed in parallel with the
>> older blas/lapack/atlas runtime library packages based on g77.
>> Therefore, if a developer wants to support parallel installability of
>> gfortran and g77 versions of his/her own runtime libs, s/he may change
>> the sonames and filenames of the gfortran-based runtime libraries as
>> well as the package names, and omit the Conflicts/Replaces stanzas in
>> the runtime library package control file section(s).
> Yes, this is possible with Camm's choice; however if you look at the
> fftw package this not done.  Are there any other libraries which are
> currently used/referenced which whould be released with lenny in both
> g77 and gfortran versions?

For backwards compatibility purposes, I don't think it's necessary to
keep the g77-based libraries actually as part of Debian for lenny.  It
ought to suffice (and I'm planning for my packages) to keep parallel
installability *possible* for gfortran- and g77-based runtime library
packages; not worth bothering for the libdevel packages though.  This
compatibility would be at the maintainer's choice, assuming that all
packages s/he depended on were also parallel-installable.

This way users can keep the obsolete g77-based runtime lib packages on
their systems, even while installing the new gfortran-based ones.  They
can also reinstall the old packages from snapshot.debian.net if needed.
 I'm adding an entry in cernlib's debian/NEWS file to that effect, also
advising that users recompile all local code with gfortran.

best regards,

Kevin B. McCarty <kmccarty@gmail.com>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: