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.
I wanted to add that I ran into this problem with octave-8.3.0-r2, control-4.0.1, and lapack-3.12.0-r1. Thanks to the info here I rebuilt sci-libs/lapack with USE flag +deprecated. After restarting octave, the pkg install command for control worked and the functions I tested ran correctly.
(In reply to Kevin Secretan from comment #5) > I wanted to add that I ran into this problem with octave-8.3.0-r2, > control-4.0.1, and lapack-3.12.0-r1. Thanks to the info here I rebuilt > sci-libs/lapack with USE flag +deprecated. After restarting octave, the pkg > install command for control worked and the functions I tested ran correctly. Thanks Kevin !!!! I was really stuck with exactly same problem , I had many test installation errors with pkg signal octave, sci-mathematics/octave-8.3.0-r2 1-) I was trying to install from octave command pkg install -forge signal "error: the following dependencies were unsatisfied: signal needs control >= 2.4" 2-) Then I tried to install control dependency pkg install -forge control many times , and no way ... >> pkg install -forge control The control package was installed into the directory /home/pentoo/.local/share/octave/api-v58/packages/control-4.0.1. License and copyright information can be found in "packinfo/COPYING" error: /home/pentoo/.local/share/octave/api-v58/packages/control-4.0.1/x86_64-pc-linux-gnu-api-v58/__control_slicot_functions__.oct: failed to load Incompatible version or missing dependency? /home/pentoo/.local/share/octave/api-v58/packages/control-4.0.1/x86_64-pc-linux-gnu-api-v58/__control_slicot_functions__.oct: undefined symbol: dgegs_ error: called from doc_cache_create>create_cache at line 116 column 20 gen_doc_cache_in_dir>@<anonymous> at line 150 column 20 doc_cache_create>gen_doc_cache_in_dir at line 151 column 9 doc_cache_create at line 62 column 12 install>generate_lookfor_cache at line 839 column 5 install at line 240 column 7 pkg at line 619 column 9 warning: load_path: /home/pentoo/.local/share/octave/api-v58/packages/control-4.0.1/x86_64-pc-linux-gnu-api-v58: No such file or directory warning: load-path: update failed for '/home/pentoo/.local/share/octave/api-v58/packages/control-4.0.1/x86_64-pc-linux-gnu-api-v58', removing from path And I tested several other things without success pkg install control-4.0.1.tar.gz (it also did not work ) till seeing your solution post !. --------------------------- Now after seeing your post, I could confirm that it was not activated the "deprecated" USE flag ,in lapack But I activated that USE FLAG in sci-libs/lapack-3.12.0-r1: + + deprecated : Also build deprecated functions And , I tried to stop emerging the binary lapack pkg and force to compile it with the new SET flag +deprecated sudo FEATURES=-getbinpkg emerge lapack -1 And after that emerge, re-starting the octave , allowed me, to smoothly install control pgk : >> pkg install -forge control The control package was installed into the directory /home/pentoo/.local/share/octave/api-v58/packages/control-4.0.1. License and copyright information can be found in "packinfo/COPYING" For information about changes from previous versions of the control package, run 'news control'. And after that , finally good signal pkg installation : >> pkg install -forge signal For information about changes from previous versions of the signal package, run 'news signal'. Thanks to all !!!
