rdlibtool: link: ln -s /dev/null .libs/libffpack_c.a.disabled rdlibtool: link: x86_64-pc-linux-gnu-g++ .libs/ffpack.o -O2 -Wall -g -pipe -march=native -fno-diagnostics-color -O2 -fabi-version=6 -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mfma -fabi-version=6 -fopenmp -lcblas -lblas -lgivaro -lgmp -lgmpxx -fopenmp -lfflas -lffpack -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -shared -fPIC -Wl,--no-undefined -Wl,-soname -Wl,libffpack_c.so.1 -o .libs/libffpack_c.so.1.0.0 /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lfflas /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lffpack collect2: error: ld returned 1 exit status rdlibtool: exec error upon slbt_exec_link_create_library(), line 1555: (see child process error messages). rdlibtool: < returned to > slbt_exec_link(), line 1985. ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_systemd-20210419-131016 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.1 [2] x86_64-pc-linux-gnu-11.1.0 * clang version 12.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/12/bin /usr/lib/llvm/12 12.0.0 Python 3.8.9 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby30 (with Rubygems) * Available Rust versions: [1] rust-bin-1.51.0 [2] rust-1.51.0 * The following VMs are available for generation-2: *) AdoptOpenJDK 8.292_p10 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.10.4 [1] php7.3 [2] php7.4 [3] php8.0 * timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Sun May 2 15:50:17 UTC 2021 emerge -qpvO sci-libs/fflas-ffpack [ebuild N ] sci-libs/fflas-ffpack-2.4.3 USE="openmp -static-libs" CPU_FLAGS_X86="avx avx2 fma3 sse3 sse4_1 sse4_2 ssse3 -avx512dq -avx512f -avx512vl -fma4"
Created attachment 705399 [details] emerge-info.txt
Created attachment 705402 [details] emerge-history.txt
Created attachment 705405 [details] environment
Created attachment 705408 [details] etc.portage.tar.bz2
Created attachment 705411 [details] logs.tar.bz2
Created attachment 705414 [details] sci-libs:fflas-ffpack-2.4.3:20210502-160902.log
Created attachment 705417 [details] temp.tar.bz2
Failure looks specific to using slibtool but note fflas-ffpack needs to not be already installed to reproduce or else it links with the system's.
Traditional libtool uses a path to the compiled fflas and ffpack libraries. libtool: link: x86_64-pc-linux-gnu-g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/crtbeginS.o .libs/fflas_lvl1.o .libs/fflas_lvl2.o .libs/fflas_lvl3.o .libs/fflas_sparse.o -Wl,-rpath -Wl,/dev/shm/portage/sci-libs/fflas-ffpack-2.4.3/work/fflas-ffpack-2.4.3/fflas-ffpack/interfaces/libs/.libs ../../../fflas-ffpack/interfaces/libs/.libs/libfflas.so -lcblas -lblas -lgivaro -lgmp -lgmpxx -Wl,--as-needed -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib64/crtn.o -O2 -g -march=native -O2 -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mfma -fopenmp -fopenmp -Wl,-O1 -fopenmp -Wl,-soname -Wl,libfflas_c.so.1 -o .libs/libfflas_c.so.1.0.0 I'd say that is an issue with how slibtool handles internal libraries. Makes me wonder what it would do to singular.
This is clearly a lapack bug, see: https://wiki.gentoo.org/wiki/Slibtool#ld_cannot_find_linker_flag They should be linking internal libraries with the libtool archives (.la) files, not with linker flags that should only be used with external dependencies.
I meant ffpack ofc...
I made a PR upstream to fix this. https://github.com/linbox-team/fflas-ffpack/pull/339
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6f7751c4da8814e15108b87c079e0312c2e6cfd commit f6f7751c4da8814e15108b87c079e0312c2e6cfd Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2021-08-07 12:20:21 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2021-08-07 12:55:07 +0000 sci-libs/fflas-ffpack: fix linking with slibtool. I've backported the patch from upstream PR 339 to fix this issue in the release tarball. I had intended to wait for an upstream comment... but we might be waiting a while. Thanks to orbea for debugging and fixing the problem! Closes: https://bugs.gentoo.org/787746 Package-Manager: Portage-3.0.20, Repoman-3.0.2 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sci-libs/fflas-ffpack/fflas-ffpack-2.4.3-r1.ebuild | 1 + .../fflas-ffpack-2.4.3-fix-internal-linking.patch | 70 ++++++++++++++++++++++ 2 files changed, 71 insertions(+)
Merged upstream. https://github.com/linbox-team/fflas-ffpack/commit/f4d3d81c199e0d0904706a4be41f551b7a24d889