bugGNU Octave - Bugs: bug #63370, Provide configuration/runtime...

 
 

bug #63370: Provide configuration/runtime tests for gejsv in svd_driver()

Submitter:  None
Submitted:  Tue 15 Nov 2022 07:53:39 AM UTC
 
Category:  Configuration and Build System Severity:  1 - Wish
Priority:  3 - Low Item Group:  Build Failure
Status:  Confirmed Assigned to:  None
Originator Name:  Thomas Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Wed 30 Nov 2022 06:49:33 AM UTC, comment #12: 

Thanks Rik that worked well!

I've comment out the function implementation in octave-7.3.0/liboctave/numeric/svd.cc: svd<ComplexMatrix>::gejsv and svd<FloatComplexMatrix>::gejsv plus reverted the driver selection according to this (https://hg.savannah.gnu.org/hgweb/octave/rev/9b6bf68ea663) within octave-7.3.0/libinterp/corefcn/svd.cc.

Now I can build Octave-7.3.0 at my RHEL7 machine.

Thanks again for your quick and kind support!

Thomas Arndt <arndtthomas>
Tue 29 Nov 2022 03:38:57 PM UTC, comment #11: 

Using grep, gejsv is found in

liboctave/numeric/lo-lapack-proto.h
liboctave/numeric/svd.h
liboctave/numeric/svd.cc
libinterp/corefcn/svd.cc

If you want to completely remove the functionality you will need to change all 4 files.  If you only want to get rid of linking to the GEJSV symbols then you may be able to comment out just the function prototypes and usage in liboctave.  You might want to put an assert() statement in those code paths in case a user accidentally does set the driver to "gejsv".  Alternatively, edit this function in libinterp/corefcn/svd.cc and use error() if someone tries to switch the SVD driver to an unsupported value.

template <typename T>
static typename math::svd<T>::Driver
svd_driver (void)
{
  if (Vsvd_driver == "gejsv")
    return math::svd<T>::Driver::GEJSV;

Rik <rik5>
Project Administrator
Tue 29 Nov 2022 12:15:19 PM UTC, comment #10: 

I guess you'd basically have to revert this changeset:
https://hg.savannah.gnu.org/hgweb/octave/rev/9b6bf68ea663

Markus Mützel <mmuetzel>
Project Member
Tue 29 Nov 2022 12:13:15 PM UTC, comment #9: 

svd.cc - line 608-635

    // ZGEJSV
    template<>
    void
    svd<ComplexMatrix>::gejsv (char& joba, char& jobu, char& jobv,
                               char& jobr, char& jobt, char& jobp,
                               F77_INT m, F77_INT n,
                               P *tmp_data, F77_INT m1, DM_P *s_vec, P *u,
                               P *v, F77_INT nrow_v1, std::vector<P>& work,
                               F77_INT& lwork, std::vector<F77_INT>& iwork,
                               F77_INT& info)

...

svd.cc - line 637-664

    // CGEJSV
    template<>
    void
    svd<FloatComplexMatrix>::gejsv (char& joba, char& jobu, char& jobv,
                                    char& jobr, char& jobt, char& jobp,
                                    F77_INT m, F77_INT n, P *tmp_data,
                                    F77_INT m1, DM_P *s_vec, P *u, P *v,
                                    F77_INT nrow_v1, std::vector<P>& work,
                                    F77_INT& lwork,
                                    std::vector<F77_INT>& iwork, F77_INT& info)
     ...

Furthermore the corresponding prototypes within:
lo-lapack-proto.h - 538-557

  F77_RET_T
  F77_FUNC (zgejsv, ZGEJSV) (F77_CONST_CHAR_ARG_DECL,
                             F77_CONST_CHAR_ARG_DECL,
                             F77_CONST_CHAR_ARG_DECL,
                             F77_CONST_CHAR_ARG_DECL,
                             F77_CONST_CHAR_ARG_DECL,
                             F77_CONST_CHAR_ARG_DECL,
                             const F77_INT&, const F77_INT&,
                             F77_DBLE_CMPLX *, const F77_INT&, F77_DBLE *,
                             F77_DBLE_CMPLX *, const F77_INT&,
                             F77_DBLE_CMPLX *, const F77_INT&,
                             F77_DBLE_CMPLX *, const F77_INT&,
                             F77_DBLE *,       const F77_INT&,
                             F77_INT *, F77_INT&
                             F77_CHAR_ARG_LEN_DECL
                             F77_CHAR_ARG_LEN_DECL
                             F77_CHAR_ARG_LEN_DECL
                             F77_CHAR_ARG_LEN_DECL
                             F77_CHAR_ARG_LEN_DECL
                             F77_CHAR_ARG_LEN_DECL);
...

lo-lapack-proto.h - 478-496

  F77_RET_T
  F77_FUNC (cgejsv, CGEJSV) (F77_CONST_CHAR_ARG_DECL,
                             F77_CONST_CHAR_ARG_DECL,
                             F77_CONST_CHAR_ARG_DECL,
                             F77_CONST_CHAR_ARG_DECL,
                             F77_CONST_CHAR_ARG_DECL,
                             F77_CONST_CHAR_ARG_DECL,
                             const F77_INT&, const F77_INT&,
                             F77_CMPLX *, const F77_INT&, F77_REAL *,
                             F77_CMPLX *, const F77_INT&,
                             F77_CMPLX *, const F77_INT&,
                             F77_CMPLX *, const F77_INT&,
                             F77_REAL *,  const F77_INT&,
                             F77_INT *, F77_INT&
                             F77_CHAR_ARG_LEN_DECL
                             F77_CHAR_ARG_LEN_DECL
                             F77_CHAR_ARG_LEN_DECL
                             F77_CHAR_ARG_LEN_DECL
                             F77_CHAR_ARG_LEN_DECL
                             F77_CHAR_ARG_LEN_DECL);
...

Thomas Arndt <arndtthomas>
Tue 29 Nov 2022 12:01:22 PM UTC, comment #8: 

I've checked the source code and found those symbols within svd.cc and lo-lapack-proto.h. So the suggestion is to remove those code sections?

Could you please point me to the sections I've to remove.

Thanks in advanced!

KR,
Thomas

Thomas Arndt <arndtthomas>
Mon 21 Nov 2022 05:39:07 PM UTC, comment #7: 

comment #6:

> Understand - a version switch to disable these newer features could be an option. But I know this will end-up in a #ifdef hell ;-).
> I'm fine with patching the version and remove those function calls. However could you please comment which features are getting removed  doing so? If it's a very special feature I don't care, but if it's more central removing could be an issue.


No special feature.  The only thing missing will be the third driver routine for SVD and the other two work well.

Rik <rik5>
Project Administrator
Mon 21 Nov 2022 09:36:06 AM UTC, comment #6: 

Understand - a version switch to disable these newer features could be an option. But I know this will end-up in a #ifdef hell ;-).
I'm fine with patching the version and remove those function calls. However could you please comment which features are getting removed  doing so? If it's a very special feature I don't care, but if it's more central removing could be an issue.

Thomas Arndt <arndtthomas>
Wed 16 Nov 2022 02:19:50 PM UTC, comment #5: 

I agree with Rik's comment #4.  I'm not interested in trying to support building (or just running, since as we've noted, lapack and blas libraries can be swapped after Octave is installed).

Regarding the more general problem of building Octave on obsolete systems:

Supporting (or even just being able to build) current versions of Octave on older systems with older versions of packages is what originally prompted me to modify MXE to allow native builds on Linux systems.

That was in the days before container systems like snap or docker were widely available on all modern distributions.  Now, if you need to run current Octave on an old Linux system and for some reason can't upgrade to the current version of your OS, maybe consider a container solution.

If your system is so old that it doesn't support those container systems, then you could try using mxe-octave to build the current version of Octave and recent versions of all the required dependencies.  However, I currently have no interest in maintaining mxe-octave for native builds.

And if your system is so old that it doesn't support those container systems, then I think you are really in the realm of retro computing and I don't understand why you want retro computing for the OS and dependencies but not for Octave.

John W. Eaton <jwe>
Project Administrator
Tue 15 Nov 2022 05:49:58 PM UTC, comment #4: 

To completely support systems which might or might not have an up-to-date BLAS library would require both configure tests and runtime checks.  I'm not opposed to that, but I don't have the time to implement it.  If a changeset is provided I could review.

Otherwise, there are two straightforward approaches.  Approach #1: Build BLAS/LAPACK from modern sources.  Approach #2: Remove the relevant code from Octave.

Approach #1 has the advantage that you will probably also pick up other bug fixes and improvements to the base libraries.

Approach #2 isn't very hard which might be appealing.  If you go that way I would do the changes once and make a patch which you could then apply whenever you build from new Octave sources.

Rik <rik5>
Project Administrator
Tue 15 Nov 2022 11:34:47 AM UTC, comment #3: 

> If users need to build newer versions on those systems, would it be acceptable for them to also build newer versions of dependencies?


Yes, completely. Building current versions of Octave on older systems cannot be done without significant effort.

@OP: if you're trying to reuse old and slow hardware, you could look into a lightweight version of a modern OS instead of an older OS like RHEL 6.

Arun Giridhar <arungiridhar>
Project Member
Tue 15 Nov 2022 09:50:56 AM UTC, comment #2: 

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?

Markus Mützel <mmuetzel>
Project Member
Tue 15 Nov 2022 09:24:35 AM UTC, comment #1: 

calls to cgejsv/zgejsv were apparently introduced in this changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/9b6bf68ea663

Indeed om my RHEL 6, liblapack 3.2.1 does not have cgejsv/zgejsv

nm /usr/lib64/liblapack.a | grep ejsv
dgejsv.o:
0000000000000000 T dgejsv_
sgejsv.o:
0000000000000000 T sgejsv_

I link octave to an openblas I compiled myself, that does come with cgejsv/zgejsv.

Assuming the RHEL 7 liblapack also lacks cgejsv/zgejsv, I guess the options available are convincing your vendor to supply a lapack version with the complex gejsv versions, switch to openblas, or maybe there is another precompiled lapack available (atlas?)

A.R. Burgers <arb>
Tue 15 Nov 2022 07:53:39 AM UTC, original submission:  

Hi guys,

I've faced a linker error as far as I could see related to lapack, blas version of the base RHEL7 system.

  CXXLD    src/octave-cli
/usr/local/gcc-9.4.0_RHEL7/bin/../lib/gcc/x86_64-redhat-linux/9.4.0/../../../../x86_64-redhat-linux/bin/ld: liboctave/.libs/liboctave.so: undefined reference to `cgejsv_'
/usr/local/gcc-9.4.0_RHEL7/bin/../lib/gcc/x86_64-redhat-linux/9.4.0/../../../../x86_64-redhat-linux/bin/ld: liboctave/.libs/liboctave.so: undefined reference to `zgejsv_'

The last working version is 6.4.0. I've tried to jump to 7.3.0 (which fails with the same error, but already face it with 7.1.0)

Is there a way to disable somehow lapack,blas or reduce the feature, compat mode or something?

Building lapack, blas is unfortunately not an option.

KR,
Thomas

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by arndtthomas (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by arb (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-11-16 mmuetzel Item GroupInstallation Failure Build Failure
        Release7.1.0 dev
        Operating SystemGNU/Linux Any
    2022-11-15 rik5 Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
        StatusNone Confirmed
        Summaryliboctave.so: undefined reference to `cgejsv_' while building from scratch gcc-9.4.0 + RHEL7 Provide configuration/runtime tests for gejsv in svd_driver()

    Back to the top


    Powered by Savane 3.9