When building an octave external code interface module the mkoctfile tries to link in some additional libraries (octave and octinterp) which it shouldn't. Those libraries are located under a non-standard path (/usr/lib64/octave/6.4.0/), so the linker fails. sci-mathematics/octave-5.2.0 was not affected. There are a couple of other bugs caused by this regression: #835021 #836945 ================================ How to Reproduce: -------------------------------- cat >helloworld.cpp <<EOF #include <octave/oct.h> DEFUN_DLD (helloworld, args, nargout, "Hello World Help String") { octave_stdout << "Hello World!\n"; return octave_value_list (); } EOF mkoctfile helloworld.cc -v -------------------------------- Sample Output: 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-6.4.0/octave/.. -I/usr/include/octave-6.4.0/octave -fopenmp -O2 -march=ivybridge -pipe helloworld.cc -o /tmp/oct-1hEggE.o x86_64-pc-linux-gnu-g++ -I/usr/include/octave-6.4.0/octave/.. -I/usr/include/octave-6.4.0/octave -fopenmp -O2 -march=ivybridge -pipe -o helloworld.oct /tmp/oct-1hEggE.o -shared -Wl,-Bsymbolic -Wl,-O1 -Wl,--as-needed -L/usr/lib64 -Wl,-O1 -Wl,--as-needed -loctinterp -loctave /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -loctinterp /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -loctave collect2: error: ld returned 1 exit status Reproducible: Always
It looks like the issue is caused by `--enable-link-all-dependencies` config option which according to comments was added in order to fix bug #776583. I'm not sure what it actually does, but removing it fixes the issue. -------------------------------- $ mkoctfile helloworld.cc -v 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-6.4.0/octave/.. -I/usr/include/octave-6.4.0/octave -fopenmp -O2 -march=ivybridge -pipe helloworld.cc -o /tmp/oct-FB5Cj4.o x86_64-pc-linux-gnu-g++ -I/usr/include/octave-6.4.0/octave/.. -I/usr/include/octave-6.4.0/octave -fopenmp -O2 -march=ivybridge -pipe -o helloworld.oct /tmp/oct-FB5Cj4.o -shared -Wl,-Bsymbolic -Wl,-O1 -Wl,--as-needed -L/usr/lib64 -Wl,-O1 -Wl,--as-needed -------------------------------- Note that "-loctinterp -loctave" are no longer present. Those are sourced from the default value for the OCT_LINK_DEPS variable. Running mkoctfile like `OCT_LINK_DEPS=" " mkoctfile helloworld.cc` doesn't produce an error.
Hi, I'm the one who added "--enable-link-all-dependencies" to the ./configure command. On its own, I still think that change is correct, because otherwise --no-undefined is passed to the libtool but at various points in the build some symbols are left undefined (namely those defined in liboctave and liboctinterp). I think the bug here is that mkoctfile is passing only -L/usr/lib64 to the linker, but the required flag is -L/usr/lib64/octave/6.4.0/ (and it knows this). And in fact octave-7.2.0 seems to be doing the right thing for me. With your example, $ mkoctfile helloworld.cpp -v 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-7.2.0/octave/.. -I/usr/include/octave-7.2.0/octave -pthread -fopenmp -O2 -pipe -march=native helloworld.cpp -o /tmp/oct-94Mt94.o x86_64-pc-linux-gnu-g++ -I/usr/include/octave-7.2.0/octave/.. -I/usr/include/octave-7.2.0/octave -pthread -fopenmp -O2 -pipe -march=native -o helloworld.oct /tmp/oct-94Mt94.o -shared -Wl,-Bsymbolic -Wl,-O1 -Wl,--as-needed -L/usr/lib64/octave/7.2.0 -L/usr/lib64 -shared -Wl,-Bsymbolic -Wl,-O1 -Wl,--as-needed -fuse-ld=mold -loctinterp -loctave Notice that the -L/usr/lib64/octave/7.2.0 flag is present, and everything works how it should. Does v7.2.0 work for you?
(In reply to Michael Orlitzky from comment #2) > Hi, I'm the one who added "--enable-link-all-dependencies" to the > ./configure command. On its own, I still think that change is correct, > because otherwise --no-undefined is passed to the libtool but at various > points in the build some symbols are left undefined (namely those defined in > liboctave and liboctinterp). > As for description `--enable-link-all-dependencies` sounds more like it meant to be used for some semi-broken systems. Wouldn't `--disable-no-undefined` flag be more suitable for this ? Though I assume it just because of the names and I may be wrong here as I'm no autotools/libtool guru and I haven't dig the build of octave thoroughly enough. > Notice that the -L/usr/lib64/octave/7.2.0 flag is present, and everything > works how it should. Does v7.2.0 work for you? Yes, Looks like the 7.2.0 compile *.oct files fine; flann(Bug #835021) compiles as well... Although I still don't like that mkoctfile links additional libraries which aren't necessary... But if you are positive about leaving the flag as-is, I would suggest to backport the patch[1] that fixes the directory issue to 6.4.0. [1]: https://github.com/gnu-octave/octave/commit/5ddada760e4d5f46fbe009a610401777f4621ed9
Also looks like that octave-7.2.0 doesn't pass "no-undefined" by default on most platforms...
(In reply to Fat-Zer from comment #4) > Also looks like that octave-7.2.0 doesn't pass "no-undefined" by default on > most platforms... Indeed, I think I can drop --enable-link-all-dependencies again from v7.2.0. I've just built it with slibtool and the original problem requiring the workaround is gone.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0ff312a62959b56777f3557cd7c6b9b1b36d7cff commit 0ff312a62959b56777f3557cd7c6b9b1b36d7cff Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2022-09-11 12:33:36 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2022-09-11 12:42:04 +0000 sci-mathematics/octave: remove slibtool workaround from v7.2.0. The --enable-link-all-dependencies flag is apparently no longer needed with octave-7.2.0. Removing it from the ./configure invocation prevents mkoctfile from using the -loctave and -loctinterp flags by default. With octave-7.2.0 they should be harmless anyway, but it's nice to clean things up a bit when we can get away with it. Bug: https://bugs.gentoo.org/776583 Bug: https://bugs.gentoo.org/858554 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../octave/{octave-7.2.0.ebuild => octave-7.2.0-r1.ebuild} | 5 ----- 1 file changed, 5 deletions(-)
We have one bug (#864785) for v7.2.0 that I don't think is new. If no surprises come up in the near future I'd rather solve this by stabilizing v7.2.0 rather than by backporting a patch, since that would require re-stabilization (of 6.4.0) anyway.
(In reply to Michael Orlitzky from comment #7) Version 6.4.0 will likely be around in tree for a while even after stabilization of 7.2.0... It would be a bit annoying to add made-up version restrictions to other packages that provide octave integration... So could you consider to replace `--enable-link-all-dependencies` with `--disable-no-undefined` in 6.4.0 as well?
(In reply to Michael Orlitzky from comment #7) > We have one bug (#864785) for v7.2.0 that I don't think is new. If no > surprises come up in the near future I'd rather solve this by stabilizing > v7.2.0 rather than by backporting a patch, since that would require > re-stabilization (of 6.4.0) anyway. Yeah, that'd be fine with me. I think do so at your leisure. I'm not using Octave daily at the moment, so don't feel well-placed to make the call.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee828164174dac808cc0b37b9306871b45857246 commit ee828164174dac808cc0b37b9306871b45857246 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2022-09-11 22:26:15 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2022-09-11 22:29:56 +0000 sci-mathematics/octave: better slibtool fix in v6.4.0. The --enable-link-all-dependencies flag was added to octave-6.4.0 to fix the build with slibtool, but that had some unintended consequences (bug 858554). The whole thing is moot in v7.2.0, but there's a better fix for v6.4.0: using --disable-no-undefined, which, double-negatively, allows for undefined symbols wherever they were causing problems. It still builds OK with rlibtool, ship it! Closes: https://bugs.gentoo.org/858554 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sci-mathematics/octave/octave-6.4.0-r4.ebuild | 215 ++++++++++++++++++++++++++ 1 file changed, 215 insertions(+)
(In reply to Fat-Zer from comment #8) > (In reply to Michael Orlitzky from comment #7) > > So could you consider to replace `--enable-link-all-dependencies` with > `--disable-no-undefined` in 6.4.0 as well? Sure thing, done. Thanks for finding that.
