Re: RFR: src:lapack's 64bit-indexing variant
Hi Sébastien,
On 2019-08-20 15:26, Sébastien Villemot wrote:
> I pushed a few further commits from myself to address some remaining
> issues. The main one concerns the override to dh_makeshlibs that you
> had removed, but which is really needed so that packages have the
> correct DEBIAN/shlibs file generated.
OK
> The only change that I’d like you to do now is to add DEP-3 headers to
> makefile-blas-remove-dep.patch.
The intention of that patch is to remove a makefile dependency to
avoid unwanted recompilation that would fail due to our special
manual builds...
> Otherwise things look good, and you can proceed with the upload (to
> experimental, since we have to go through NEW, and because of the new
> source-only uploads policy).
Got it. But keep in mind that we haven't adapted the rules/control
for 32-bit architectures -- they don't support BLAS64/LAPACK64.
I'll add some guards in rules later and test it in an i386 env.
>> 2. Upstream CBLAS code is not ready for the
>> 64bit-indexing feature. the upstream somehow postponed
>> this feature[1]. As a result, I didn't deal with
>> the CBLAS build and CBLAS development files.
>> I can patch CBLAS, but let's do it when the
>> 64bit variant of OpenBLAS is available.
>>
>> 3. the test packages and autopkgtest updates are
>> postponed by me. Let's finalize them in the
>> next round of src:lapack update with the
>> CBLAS64 patch.
>
> If I understand correctly, your intention is to fix these two remaining
> issues in a subsequent upload? That's fine with me, as long as we don't
> forget them.
I've added the autopkgtest for the BLAS64/LAPACK64 libraries,
and my local sbuild+autopkgtest tests are clean. So (3.) has
been resolved.
I mean the CBLAS code is not ready for the 64-bit indexing feature until
I (or somebody else) patched it. Let's postpone the patching work and
first get OpenBLAS's 64bit variant uploaded.
My plan:
1. upload src:lapack for BLAS64/LAPACK64 (we omit CBLAS64 temporarily)
2. upload src:openblas for the indexing variants and threading
variants (libopenblas64.so needs liblapack64-pic.a to build)
and we have to add an extra libjulia-openblas package,
providing a special build for the julia package
libjulia-openblas will ship libopenblas64_.so
(soname=libopenblas64_.so), with all BLAS/LAPACK symbols
mangled (suffixing "64_")
3. Add bin:libjulia-suitesparse to src:suitesparse
libjulia-suitesparse will be built with the '-DSUN64' (IIRC)
compiler flag, against libjulia-openblas.
4. remove src:julia's vendored suitesparse source and openblas
source.
5. patch CBLAS for the 64-bit indexing support
(then we can announce that all the BLAS64/LAPACK64 libraries
are switchable.)
All related source packages are maintained by you.
Does these plans look good to you?
Reply to: