Bug 1295965 - Add 64-bit integer (ILP64) interface library with 64_ symbol suffix
Add 64-bit integer (ILP64) interface library with 64_ symbol suffix
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lapack (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
: Tracking
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-05 17:55 EST by Orion Poplawski
Modified: 2017-08-15 11:27 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-14 15:03:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2016-01-05 17:55:15 EST
Description of problem:

We're starting to develop a convention of BLAS/LAPACK libraries with an ILP64 interface having symbols with a 64_ suffix in a library with a 64_ suffix (see bug #1088256).  I think we need to implement this for the netlib blas/lapack to avoid issues with openblas and some symbols having the 64_ suffix (from openblas) and some without (from lapack).
Comment 1 Susi Lehtola 2016-01-07 14:44:19 EST
Or another possibility would be to just use the bundled version of lapack in openblas (and atlas). That way we would also avoid issues like bug #1287405: there's no guarantee that the system version of lapack and openblas will be in sync otherwise...
Comment 2 Orion Poplawski 2016-01-07 15:05:58 EST
That's probably the thing to do.
Comment 3 Milan Bouchet-Valat 2016-01-08 06:12:09 EST
I wonder whether having an ILP64 LAPACK with the 64_ suffix would make it easier to build ILP64 versions of ARPACK and SuiteSparse. Maybe we can link them against OpenBLAS, but better be sure of that.
Comment 4 Jan Kurik 2016-02-24 09:14:05 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 5 Fedora End Of Life 2017-07-25 15:43:42 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 6 Tom "spot" Callaway 2017-08-01 13:03:21 EDT
Willing to take patches here, but I'm not entirely sure what needs to happen, aside from the library naming. Are there custom compiler flags that need to be used, are there specific parts of lapack that need to be enabled/disabled?
Comment 7 Susi Lehtola 2017-08-01 19:49:25 EDT
I think the only changes that are necessary are
- compiling with 64-bit integers i.e. -fdefault-integer-8 
- adding a 64_ suffix to all symbols and
- adding a 64_ suffix to the library name.
Comment 8 Tom "spot" Callaway 2017-08-09 12:34:59 EDT
Two of those are easy. One will require a giant patch that will almost certainly have to be rebased every time lapack changes. Is there a clever way to suffix the symbols without that pain?
Comment 9 Susi Lehtola 2017-08-11 02:09:47 EDT
OpenBLAS has a make option for the suffixes, and I'm guessing that also holds for ATLAS.

Here's how they did it in OpenBLAS
https://github.com/xianyi/OpenBLAS/pull/459
Comment 10 Tom "spot" Callaway 2017-08-14 15:03:13 EDT
Okay. I've applied the changes in rawhide, specifically in lapack-3.7.1-4.fc27. The lapack64 and blas64 subpackages contain 64_liblibpack and 64_libblas libraries, with all the symbols suffixed with 64_, and -fdefault-integer-8.
Comment 11 Susi Lehtola 2017-08-14 16:36:29 EDT
(In reply to Tom "spot" Callaway from comment #10)
> Okay. I've applied the changes in rawhide, specifically in
> lapack-3.7.1-4.fc27. The lapack64 and blas64 subpackages contain
> 64_liblibpack and 64_libblas libraries, with all the symbols suffixed with
> 64_, and -fdefault-integer-8.

I mean, the libraries should be called liblapack64_ and libblas64_, not 64_liblapack and 64_libblas...?
Comment 12 Tom "spot" Callaway 2017-08-15 11:27:23 EDT
Okay. They're named that way in -5.

Note You need to log in before you can comment on or make changes to this bug.