Summary: | sci-mathematics/octave-5.2.0 - pkg install -forge control: /home/dechcaudron/octave/control-3.2.0/x86_64-pc-linux-gnu-api-v53/__control_slicot_functions__.oct: failed to load: undefined symbol: dgegs_ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Héctor Barreras <dechcaudron> |
Component: | Current packages | Assignee: | Gentoo Science Mathematics related packages <sci-mathematics> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dechcaudron, gentoo, harrisl, mjo, simao_amorim |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge --info |
Description
Héctor Barreras
2020-06-30 09:21:36 UTC
I believe this is caused by a problem in slicot, which the control package depends on. It appears as though the control package depends on version 5 of slicot and this code can be found in slicot.tar.gz within the src directory of control-3.2.0.tar.gz. Several of the routines found within depend on the eigenvalue routine dgegs, which was deprecated and removed from LAPACK starting from v3.6.0. Instead, dgegs should be replaced with dgges. Unfortunately, the calling sequence is different for this routine, so it's not as simple as a regex to fix the code. Now, the real place for this to be fixed is probably with slicot. However, slicot appears to have moved to a closed source model and I don't see any updates that fix this issue. On the Gentoo side, the package lapack-reference is actually all of the way back on 3.2.1-r4, which would probably work. Unfortunately, I think Gentoo has moved on to virtual/lapack and app-eselect/eselect-lapack which are at version 3.8. As such, the current LAPACK setup, which is actually pretty nice, doesn't work for slicot and hence breaks the control package. Now, it looks like the macports folks ran into this problem: https://trac.macports.org/browser/trunk/dports/math/octave-control/files/patch-src-Makefile.diff?rev=153772 Essentially, they modified the Makefile in the src directory of the control package with: # unpack and compile SLICOT library # Note that TG04BX is a custom routine. # It has the extension .fortran such that # it is not deleted by rm *.f when using # the developer makefile makefile_control.m slicotlibrary.a: slicot.tar.gz tar -xzf slicot.tar.gz sed -i'.orig' 's/DGEGS/DGGES/g' slicot/src/SG03AD.f slicot/src/SG03BD.f sed -i'.orig' 's/DLATZM/DORMRZ/g' slicot/src/AB08NX.f slicot/src/AG08BY.f slicot/src/SB01BY.f slicot/src/SB01FY.f Basically, they added two sed lines. I just tried this and it will compile. That said, I'm pretty sure that if that routine ever gets called that depends on DGEGS it will crash because the calling sequence for DGGES is not the same: https://www.netlib.org/lapack/explore-html/d9/d8e/group__double_g_eeigen_gaf64f56e7012093f95cd35f59271b85bf.html vs https://www.netlib.org/lapack/explore-html/d9/d8e/group__double_g_eeigen_ga8637d4b822e19d10327ddcb4235dc08e.html But, you know, most of the routines would still probably work if you did this change. I just did some simple control commands and it seemed to work. tldr: 1. Either a *really* old version of LAPACK (3.5 or below) needs to be installed on the system or the control package needs to be downloaded and patched by hand using the above changes. For the latter option, use pkg install /path/to/patched/control.tar.gz inside of Octave. 2. Long term, slicot should be fixed to properly use the newer dgges routine. Slicot is currently closed source, so the last open version needs to be patched, which may be version 5. Thanks for looking into it hfk22, I really appreciate your help. I've sent an email to the maintainers of the Control package according to Octave Forge with a link to this thread to see if it can be fixed upstream. I understand there is little we can do to get it fixed for good if they cannot provide assistance, but the manual fix will work in a pinch. Cheers! Hello,
After facing this same exact problem, I tried to install the control
package on a manually installed octave-5.1.0 and it worked fine
(with just a couple warnings about deprecated LFLAGS).
It seemed weird why the same version of the control pkg (3.2.0)
worked on 5.1.0 and not in 5.2.0, so after a couple hours I found
out I was running 5.1.0 as root and 5.2.0 as a normal user.
It turns out that running:
>>> pkg install -forge control
while running the octave-5.2.0 ebuild as root works fine
(I tried the -local flag and it does NOT work).
Now, I still haven't tested the actual functions, but documentation
works so I guess this could be a case of misleading
output from the pkg command? Trying to say it should be run as root
and not as a normal user?
Best regards,
Simão A.
I'm sorry no one responded to this sooner. I've tried to reproduce the problem, but it looks like everything is working as expected with the latest versions of octave/control: mjo $ octave octave: no graphical display found octave: disabling GUI features GNU Octave, version 7.3.0 ... octave:1> pkg install "/home/mjo/tmp/octave/control-3.4.0.tar.gz" For information about changes from previous versions of the control package, run 'news control'. octave:2> pkg load control octave:3> pkg list Package Name | Version | Installation directory --------------+---------+----------------------- control *| 3.4.0 | .../.local/share/octave/api-v57/packages/control-3.4.0 If anyone is still experiencing this issue, please feel free to reopen the bug. |