slibtool: link: x86_64-pc-linux-gnu-ar crs libinterp/dldfcn/.libs/fftw.a libinterp/dldfcn/.libs/fftw_la-fftw.o slibtool: link: mpicxx libinterp/dldfcn/.libs/fftw_la-fftw.o -fPIC -fopenmp -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -Os -pipe -ma rch=native -Os -pipe -march=native -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -lfftw3_threads -lfftw3 -lfftw3f_threads -lfftw3f -lutil -lm -shared -fPIC -Wl,--no-undefined -o libinterp/dldfcn/.libs/fftw.so /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: libinterp/dldfcn/.libs/fftw_la-fftw.o: in function `octave_value::operator=(octave_value&&) [clone .isra.0]': fftw.cc:(.text+0xc1): undefined reference to `octave_value::nil_rep()' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: libinterp/dldfcn/.libs/fftw_la-fftw.o: in function `Gfftw': fftw.cc:(.text+0x13c): undefined reference to `check_version(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std:: allocator<char> > const&)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x17f): undefined reference to `octave_dld_function::create(octave_value_list (*)(octave_value_list const&, int), oc tave::dynamic_library const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: libinterp/dldfcn/.libs/fftw_la-fftw.o: in function `Ffftw(octave_value_list const&, int)': fftw.cc:(.text+0x230): undefined reference to `print_usage()' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x235): undefined reference to `octave_value::nil_rep()' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x25c): undefined reference to `octave_value::xstring_value[abi:cxx11](char const*, ...) const' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x2ba): undefined reference to `octave_value::xstring_value[abi:cxx11](char const*, ...) const' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x34d): undefined reference to `error(char const*, ...)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x35d): undefined reference to `octave::fftw_planner::instance_ok()' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x368): undefined reference to `octave::fftw_planner::instance' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x373): undefined reference to `octave::fftw_planner::do_method(octave::fftw_planner::FftwMethod)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x385): undefined reference to `octave::float_fftw_planner::instance_ok()' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x397): undefined reference to `octave::float_fftw_planner::instance' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x3a2): undefined reference to `octave::float_fftw_planner::do_method(octave::float_fftw_planner::FftwMethod)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x3b8): undefined reference to `octave_value::octave_value(char const*, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x3e1): undefined reference to `octave_value::octave_value(char const*, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x402): undefined reference to `octave_value::octave_value(char const*, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x423): undefined reference to `octave_value::octave_value(char const*, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x43f): undefined reference to `octave_value::octave_value(char const*, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x45f): undefined reference to `octave::fftw_planner::instance_ok()' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x46a): undefined reference to `octave::fftw_planner::instance' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x472): undefined reference to `octave::fftw_planner::do_method()' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x496): undefined reference to `octave_value::octave_value(char const*, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x4ba): undefined reference to `octave_value::octave_value(char const*, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x4de): undefined reference to `octave_value::octave_value(char const*, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x502): undefined reference to `octave_value::octave_value(char const*, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x521): undefined reference to `octave_value::octave_value(char const*, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x594): undefined reference to `octave_value::xstring_value[abi:cxx11](char const*, ...) const' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x5af): undefined reference to `error(char const*, ...)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x5eb): undefined reference to `error(char const*, ...)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x5fb): undefined reference to `octave_value::octave_value(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x63e): undefined reference to `error(char const*, ...)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x661): undefined reference to `octave_value::octave_value(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x6d4): undefined reference to `octave_value::xstring_value[abi:cxx11](char const*, ...) const' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x6ef): undefined reference to `error(char const*, ...)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x72b): undefined reference to `error(char const*, ...)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x73b): undefined reference to `octave_value::octave_value(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x766): undefined reference to `error(char const*, ...)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fftw.cc:(.text+0x789): undefined reference to `octave_value::octave_value(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)'
Created attachment 691638 [details] buildlog
Try using rlibtool instead of slibtool, slibtool, slibtool-static and slibtool-shared should only be used for a few special cases that use libtool, but not autotools.
(In reply to orbea from comment #2) > Try using rlibtool instead of slibtool [...] I'm getting undefined references with rlibtool as well (or at least with same USE, haven't tested every combinations but I think many are affected). rlibtool: link: x86_64-pc-linux-gnu-g++ libinterp/dldfcn/.libs/__fltk_uigetfile___la-__fltk_uigetfile__.o -fPIC -pthread -fopenmp -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -march=native -O2 -pipe -fdiagnostics-color=always -frecord-gcc-switches -L/usr/lib64/fltk -Wl,-rpath,/usr/lib64/fltk -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -lfltk_gl -lGLU -lGL -lfltk -lXrender -lXcursor -lXfixes -lXext -lXft -lfontconfig -lXinerama -lpthread -ldl -lm -lX11 -lfreetype -lutil -lm -shared -fPIC -Wl,--no-undefined -o libinterp/dldfcn/.libs/__fltk_uigetfile__.so rlibtool: exec error upon slbt_exec_link_create_library(), line 1446: (see child process error messages). rlibtool: < returned to > slbt_exec_link(), line 1836. [...] /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: __delaunayn__.cc:(.text+0x269): undefined reference to `dim_vector::nil_rep()'
Now your issue looks more expected. Unfortunately the octave build has been known to be broken for a while and was not trivial to fix when last checked as they were using non-portable undefined behavior from GNU libtool. (Which is probably still the case?) Additionally you may get a more helpful logs using slibtool-9999 and rdlibtool. When using slibtool directly you are explicitly building both shared and static libraries while rlibtool uses the result of --{enable,disable}-{shared,static} from the configure script. Respectively dlibtool and rdlibtool provide more verbose debugging output, additionally slibtool-9999 has changes helpful for debugging that have not yet made it into a release. In short you should use rlibtool for almost everything, slibtool or slibtool-{shared,static} for the few things that use libtool, but not autotools and dlibtool or rdlibtool for debugging. There is also clibtool, clibtool-{shared,static}, dclibtool and rdclibtool for when installing the .la files is desired. In most cases you do not want them installed, but there are a few programs that actually depend on them being there which ideally should be fixed.
(In reply to orbea from comment #4) > In short you should use rlibtool for almost everything [...] For the record, every bugs I've assigned where the report used slibtool directly, I've tried rlibtool to check validity. So you can assume these fail with rlibtool as well. It would be simpler if just used rlibtool in the first place as mentioned though.
In the case of an eventual switch to slibtool we have to choose which variant to use (and only one). I leave to polynomialC the decision
(In reply to Alessandro Barbieri from comment #6) > In the case of an eventual switch to slibtool we have to choose which > variant to use (and only one). I leave to polynomialC the decision Sounds to me no --heuristics by default will just increase amount of fixes needed with no real benefit, while rlibtool's tries to be smart to solve thing for us. In cases where rlibtool doesn't work but another does, I guess we could have some function to switch variants in the future if no better fix by then.
I agree the situation is not ideal, here is one possible workaround for a case where rlibtool will not work. https://github.com/libtom/libtomcrypt/pull/433 But this is not applicable everywhere.
*** Bug 782118 has been marked as a duplicate of this bug. ***
The underlinking is actually easy to fix. To my ongoing amusement, the ./configure script has two flags, --enable-no-undefined (default on) --enable-link-all-dependencies (default off) Obviously, the default values will only work with a libtool that ignores --no-undefined, since everything is underlinked by design. Adding --enable-link-all-dependencies fixes THAT problem, leaving me with... rlibtool: install: /usr/lib/portage/python3.9/ebuild-helpers/xattr/install -c libinterp/dldfcn/.libs/gzip.so /var/tmp/portage/sci-mathematics/octave-6.4.0/image//usr/lib64/octave/6.4.0/gzip.so preserving existing HG-ID file cd /var/tmp/portage/sci-mathematics/octave-6.4.0/image//usr/bin && \ for f in mkoctfile octave octave-cli octave-config; do \ mv $f $f-6.4.0 && \ ln -s $f-6.4.0 $f; \ done make[4]: Leaving directory '/var/tmp/portage/sci-mathematics/octave-6.4.0/work/octave-6.4.0' make LIBTOOL=rlibtool install-data-hook make[4]: Entering directory '/var/tmp/portage/sci-mathematics/octave-6.4.0/work/octave-6.4.0' preserving existing HG-ID file cat libinterp/dldfcn/PKG_ADD > oct-file-pkg-add-t \ && mv oct-file-pkg-add-t oct-file-pkg-add /bin/mkdir -p /var/tmp/portage/sci-mathematics/octave-6.4.0/image//usr/share/octave/6.4.0/etc /usr/lib/portage/python3.9/ebuild-helpers/xattr/install -c -m 644 libinterp/DOCSTRINGS /var/tmp/portage/sci-mathematics/octave-6.4.0/image//usr/share/octave/6.4.0/etc/built-in-docstrings /bin/mkdir -p /var/tmp/portage/sci-mathematics/octave-6.4.0/image//usr/lib64/octave/6.4.0/oct/x86_64-pc-linux-gnu if [ -n "`cat libinterp/dldfcn/PKG_ADD`" ]; then \ /usr/lib/portage/python3.9/ebuild-helpers/xattr/install -c -m 644 oct-file-pkg-add /var/tmp/portage/sci-mathematics/octave-6.4.0/image//usr/lib64/octave/6.4.0/oct/x86_64-pc-linux-gnu/PKG_ADD; \ fi cd /var/tmp/portage/sci-mathematics/octave-6.4.0/image//usr/lib64/octave/6.4.0 && \ for ltlib in libinterp/dldfcn/__delaunayn__.la libinterp/dldfcn/__fltk_uigetfile__.la libinterp/dldfcn/__glpk__.la libinterp/dldfcn/__init_fltk__.la libinterp/dldfcn/__init_gnuplot__.la libinterp/dldfcn/__ode15__.la libinterp/dldfcn/__voronoi__.la libinterp/dldfcn/audiodevinfo.la libinterp/dldfcn/audioread.la libinterp/dldfcn/convhulln.la libinterp/dldfcn/fftw.la libinterp/dldfcn/gzip.la; do \ f=`echo $ltlib | /usr/bin//sed 's,.*/,,'`; \ dl=`/usr/bin//sed -n -e "s/dlname='\([^']*\)'/\1/p" < $f`; \ if [ -n "$dl" ]; then \ /usr/lib/portage/python3.9/ebuild-helpers/xattr/install -c $dl /var/tmp/portage/sci-mathematics/octave-6.4.0/image//usr/lib64/octave/6.4.0/oct/x86_64-pc-linux-gnu/`echo $f | /usr/bin//sed 's,^lib,,; s,\.la$,.oct,'`; \ else \ echo "error: dlname is empty in $ltlib!"; \ exit 1; \ fi; \ lnames=`/usr/bin//sed -n -e "s/library_names='\([^']*\)'/\1/p" < $f`; \ if [ -n "$lnames" ]; then \ rm -f $f $lnames $dl; \ fi \ done /bin/sh: 1: cannot open __delaunayn__.la: No such file error: dlname is empty in libinterp/dldfcn/__delaunayn__.la! make[4]: *** [Makefile:31893: install-oct] Error 1
(In reply to Michael Orlitzky from comment #10) > /bin/sh: 1: cannot open __delaunayn__.la: No such file > error: dlname is empty in libinterp/dldfcn/__delaunayn__.la! > make[4]: *** [Makefile:31893: install-oct] Error 1 And libinterp/dldfcn/__delaunayn__.la looks fine here. I don't know why it's trying to sed __delaunayn__.la without the full path.
*** Bug 825518 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c3b07b88c4c2034c849824210c3227bb0ab28bfa commit c3b07b88c4c2034c849824210c3227bb0ab28bfa Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2022-01-17 17:19:22 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2022-01-17 17:24:31 +0000 sci-mathematics/octave: new upstream version 6.4.0. Bug: https://bugs.gentoo.org/776583 Closes: https://bugs.gentoo.org/775254 Package-Manager: Portage-3.0.28, Repoman-3.0.3 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sci-mathematics/octave/Manifest | 1 + sci-mathematics/octave/octave-6.4.0.ebuild | 204 +++++++++++++++++++++++++++++ 2 files changed, 205 insertions(+)
octave relies upon non-portable internals of the .la file, so they end up failing to sed the .la files with no path. All of this is utterly terrible and will need to be gone before slibtool will work. The only reason they can get away with it is because GNU libtool is dead and thus never changes.
*** Bug 824962 has been marked as a duplicate of this bug. ***
Created attachment 764362 [details, diff] octave-6.4.0-no-libtool-hacks.patch Here's a patch to address the issue. The patch allows the build to succeed, but I don't know if it all works once installed. Please test if you get a few spare cycles.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=133a5fab561cdd253fcf32b426c8838ede7efba5 commit 133a5fab561cdd253fcf32b426c8838ede7efba5 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2022-03-17 14:26:07 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2022-03-17 14:26:22 +0000 sci-mathematics/octave: add upstream patch for slibtool support. Closes: https://bugs.gentoo.org/776583 Bug: https://savannah.gnu.org/bugs/?61905 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../octave/files/octave-6.4.0-slibtool.patch | 37 ++++++++++++++++++++++ sci-mathematics/octave/octave-6.4.0.ebuild | 1 + 2 files changed, 38 insertions(+)
Thanks a lot for getting this fixed, it has been bugging me for years!
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(-)
