Created attachment 647178 [details] emerge --info Hi, I need the 'control' package as a dependency of 'signal'. I freshly installed octave with the following USE flags: X curl doc fftw glpk gnuplot gui opengl qhull qrupdate readline sparse ssl zlib The issue is observed both when installing from local file and from forge: ``` >> pkg install -forge -verbose control <...> x86_64-pc-linux-gnu-gfortran -c -fPIC -O2 -pipe -std=legacy UE01MD.f -o UE01MD.o x86_64-pc-linux-gnu-ar -rc slicotlibrary.a ./sltmp/*.o rm -rf sltmp slicot LFLAGS=" -L/usr/lib64 -llapack -lblas -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../.. -lgfortran -lm -lquadmath" \ /usr/bin/mkoctfile-5.2.0 --verbose -Wall -Wno-deprecated-declarations __control_slicot_functions__.cc common.cc slicotlibrary.a warning: LFLAGS is deprecated and will be removed in a future version of Octave, use LDFLAGS instead x86_64-pc-linux-gnu-g++ -c -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -fPIC -I/usr/include/octave-5.2.0/octave/.. -I/usr/include/octave-5.2.0/octave -pthread -fopenmp -O2 -pipe -Wall -Wno-deprecated-declarations __control_slicot_functions__.cc -o /tmp/oct-B7QTAV.o x86_64-pc-linux-gnu-g++ -c -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -fPIC -I/usr/include/octave-5.2.0/octave/.. -I/usr/include/octave-5.2.0/octave -pthread -fopenmp -O2 -pipe -Wall -Wno-deprecated-declarations common.cc -o /tmp/oct-HJQRzT.o x86_64-pc-linux-gnu-g++ -I/usr/include/octave-5.2.0/octave/.. -I/usr/include/octave-5.2.0/octave -pthread -fopenmp -O2 -pipe -shared -Wl,-Bsymbolic -Wl,-O1 -Wl,--as-needed -Wall -Wno-deprecated-declarations -o __control_slicot_functions__.oct /tmp/oct-B7QTAV.o /tmp/oct-HJQRzT.o slicotlibrary.a -L/usr/lib64 -llapack -lblas -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../.. -lgfortran -lm -lquadmath -Wl,-O1 -Wl,--as-needed make: Leaving directory '/tmp/oct-ICEbXD/control-3.2.0/src' copyfile /tmp/oct-ICEbXD/control-3.2.0/src/__control_helper_functions__.oct /tmp/oct-ICEbXD/control-3.2.0/src/__control_slicot_functions__.oct /tmp/oct-ICEbXD/control-3.2.0/inst/x86_64-pc-linux-gnu-api-v53 /home/dechcaudron/octave/control-3.2.0/x86_64-pc-linux-gnu-api-v53/__control_slicot_functions__.oct: failed to load: /home/dechcaudron/octave/control-3.2.0/x86_64-pc-linux-gnu-api-v53/__control_slicot_functions__.oct: undefined symbol: dgegs_ error: called from doc_cache_create>create_cache at line 109 column 20 gen_doc_cache_in_dir>@<anonymous> at line 143 column 16 doc_cache_create>gen_doc_cache_in_dir at line 144 column 9 doc_cache_create at line 55 column 12 install>generate_lookfor_cache at line 799 column 5 install at line 228 column 7 pkg at line 441 column 9 ``` Honestly, I have no idea what could be causing this. I've tried a couple approaches found on forums to issues that seemed slightly related, but with no success so far. Is this a Gentoo issue or something the Octave team has to sort out?
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.
