Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK
- Date: Mon, 22 Oct 2018 18:28:34 +0100
- From: James Clarke <jrtc27@xxxxxxxxxx>
- Subject: Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK
On 22 Oct 2018, at 18:17, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote:
> On Mon, 2018-10-22 at 15:07 +0000, Mo Zhou wrote:
>> Hi Wookey and Bastian,
>> On Sun, Oct 21, 2018 at 06:51:16PM +0100, Wookey wrote:
>>> On 2018-10-21 17:16 +0200, Bastian Blank wrote:
>>>> On Sun, Oct 21, 2018 at 09:51:15AM +0000, Mo Zhou wrote:
>>>>> about naming convention of SONAME and package name.
>>>>> As discussed in , Debian will need a set of ILP64 interface
>>>>> to BLAS/LAPACK in the future.
>>>> Could you please describe what you mean? All 64-bit Debian
>>>> architectures are LP64. So building a single binary using ILP64 will
>>>> even break the ABI for glibc and it will most likely not run very far.
>>>> (A file descriptor is defined as "int", so even the most basic file
>>>> calls will be incompatible.)
>> I missed some points in the original post. The proposal meant to add
>> a new set of BLAS/LAPACK packages that are compiled in ILP64, and the
>> existing BLAS/LAPACK API/ABI won't be changed and nothing will break.
>> Here is a detailed example for demonstration
>> bin:libopenblas-base (LP64, won't be changed at all)
>> provides libblas.so.3
>> bin:libopenblas-dev (LP64, won't be changed at all)
>> provides libblas.so
>> bin:libopenblas-ilp64 (ILP64, newly-added)
>> provides libblas-ilp64.so.3
>> bin:libopenblas-ilp64-dev (ILP64, newly-added)
>> provides libblas-ilp64.so
>> So there is no "ABI bump" but just "adding a new set of ABI". At the
>> same time, it won't result in any transition or breakage.
> The way we manage different basic ABIs in Debian is to define separate
> Debian architectures. E.g. on x86-64 we have the amd64 (LP64) and x32
> (ILP32) architectures.
> How you can use an ILP64 library without also building applications for
> ILP64? And then, don't you also need libc6 built for ILP64?
So there seems to be a lot of confusion about what this is, and as an observer
I went to read  as referenced by lumin. It's rather badly written but if you
scroll down to the table under "Coding for ILP64" it becomes clear that they
are not defining a new system ABI; C's int remains 32-bit. Of course, that
makes total sense, as otherwise how can you have 8-bit, 16-bit and 32-bit
integral types in POSIX C with only char and short, not to mention all the
incompatibilities everywhere? So, like many others here I'm sure, I don't think
this should be called "ILP64" at all; it's still LP64, just everything that was
an int in the BLAS API is now a 64-bit type. I would suggest referring to it as
something like BLAS64/LAPACK64, or, if people really insist on this
awfully-confusing ILP64 terminology, at least try and disambiguate by calling
TL;DR: This is not ILP64. This is an all-64-bit variant of the BLAS/LAPACK API.