[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #63370] liboctave.so: undefined reference to `
From: |
Markus Mützel |
Subject: |
[Octave-bug-tracker] [bug #63370] liboctave.so: undefined reference to `cgejsv_' while building from scratch gcc-9.4.0 + RHEL7 |
Date: |
Tue, 15 Nov 2022 04:50:57 -0500 (EST) |
Follow-up Comment #2, bug #63370 (project octave):
IIUC, those function were added to LAPACK approx. 7 years ago:
https://github.com/Reference-LAPACK/lapack/commit/6f69800f5e1f3ad2195483c6e1154add5a58ada0
LAPACK 3.2.1 is more than 13 years old:
https://netlib.org/lapack/#_lapack_version_3_2_1
IIUC, RHEL 7 packages LAPACK 3.4.2. That version is more than 10 years old.
If such historic versions of LAPACK are still in use, we could add a configure
check and only build that part if it is available.
On the other hand, BLAS/LAPACK libraries could be exchanged after Octave was
built (e.g., via Debian's alternatives). So maybe, we'd need a run-time check.
But that might be more difficult to implement.
Having written that: The support for RHEL 6 ended in November 2020:
https://access.redhat.com/discussions/4768501
Do we want to keep support for those long maintenance systems? Isn't the point
of them that they do *not* use most recent versions of software?
If users need to build newer versions on those systems, would it be acceptable
for them to also build newer versions of dependencies?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63370>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- [Octave-bug-tracker] [bug #63370] liboctave.so: undefined reference to `cgejsv_' while building from scratch gcc-9.4.0 + RHEL7, anonymous, 2022/11/15
- [Octave-bug-tracker] [bug #63370] liboctave.so: undefined reference to `cgejsv_' while building from scratch gcc-9.4.0 + RHEL7, A.R. Burgers, 2022/11/15
- [Octave-bug-tracker] [bug #63370] liboctave.so: undefined reference to `cgejsv_' while building from scratch gcc-9.4.0 + RHEL7,
Markus Mützel <=
- [Octave-bug-tracker] [bug #63370] liboctave.so: undefined reference to `cgejsv_' while building from scratch gcc-9.4.0 + RHEL7, Arun Giridhar, 2022/11/15
- [Octave-bug-tracker] [bug #63370] Provide configuration/runtime tests for gejsv in svd_driver(), Rik, 2022/11/15
- [Octave-bug-tracker] [bug #63370] Provide configuration/runtime tests for gejsv in svd_driver(), Markus Mützel, 2022/11/16
- [Octave-bug-tracker] [bug #63370] Provide configuration/runtime tests for gejsv in svd_driver(), John W. Eaton, 2022/11/16
- [Octave-bug-tracker] [bug #63370] Provide configuration/runtime tests for gejsv in svd_driver(), Thomas Arndt, 2022/11/21
- [Octave-bug-tracker] [bug #63370] Provide configuration/runtime tests for gejsv in svd_driver(), Rik, 2022/11/21
- [Octave-bug-tracker] [bug #63370] Provide configuration/runtime tests for gejsv in svd_driver(), Thomas Arndt, 2022/11/29
- [Octave-bug-tracker] [bug #63370] Provide configuration/runtime tests for gejsv in svd_driver(), Thomas Arndt, 2022/11/29
- [Octave-bug-tracker] [bug #63370] Provide configuration/runtime tests for gejsv in svd_driver(), Markus Mützel, 2022/11/29
- [Octave-bug-tracker] [bug #63370] Provide configuration/runtime tests for gejsv in svd_driver(), Rik, 2022/11/29