cp gen_code ../../../bin rdlibtool: link: ln -s ../gen_code .libs/gen_code.exe.wrapper rdlibtool: error logged in slbt_exec_link_create_executable(), line 1761: path not found: gen_code.wrapper.tmp. rdlibtool: < returned to > slbt_exec_link(), line 2155. make[2]: *** [Makefile:343: gen_code] Error 2 make[2]: Leaving directory '/var/tmp/portage/sci-libs/ta-lib-0.4.0/work/ta-lib/src/tools/gen_code' make[1]: *** [Makefile:348: all-recursive] Error 1 ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_systemd-j2-20210515-193921 ------------------------------------------------------------------- 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.10 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby30 (with Rubygems) * Available Rust versions: [1] rust-bin-1.52.1 * 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 Tue May 18 02:50:17 UTC 2021 emerge -qpvO sci-libs/ta-lib [ebuild N ] sci-libs/ta-lib-0.4.0
Created attachment 709530 [details] emerge-info.txt
Created attachment 709533 [details] emerge-history.txt
Created attachment 709536 [details] environment
Created attachment 709539 [details] etc.portage.tar.bz2
Created attachment 709542 [details] logs.tar.bz2
Created attachment 709545 [details] sci-libs:ta-lib-0.4.0:20210518-033326.log
Created attachment 709548 [details] temp.tar.bz2
This is failing because the all-local target in the Makefile doesn't have a prerequisite on the gen_code target that is depends on. The difference in performance between GNU libtool and slibtool where the latter is much faster probably has something do with this. Additionally there are several other issues as described in the upstream issue. https://sourceforge.net/p/ta-lib/patches/6/ Mainly: * Links internal dependencies with .la files rather than -l linker flags. The -l linker flags are for external dependencies exclusively and this can break with slibtool. * Additionally slibtool will output the gen_code binary to the .libs directory while slibtool will do so in the Makefile directory. The command needs to be invoked with $(LIBTOOL) --mode=execute to correctly copy the binary and not the slibtool wrapper script for the binary. * Lastly there is a workaround for a slibtool bug where the cp(1) command is wrapped in a shell script. Invoking the command directly with --mode=execute will result in slibtool dropping the destination argument which obviously does not work. While this workaround is far from ideal, it will be portable for GNU libtool, slibtool now and slibtool when the bug is fixed.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e1e1fa5ad82974f69f122a7663bd18a1f947e53e commit e1e1fa5ad82974f69f122a7663bd18a1f947e53e Author: orbea <orbea@riseup.net> AuthorDate: 2022-05-12 19:41:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-05-13 22:45:56 +0000 sci-libs/ta-lib: Fix build with slibtool This fixes several issues with the build: * Renames configure.in to configure.ac as is standard. * Adds detection to configure.ac for libm to replaced the hardcoded instances of -lm. * Links internal dependencies with .la files rather than -l linker flags. The -l linker flags are for external dependencies exclusively and this can break with slibtool. * With slibtool there is a parellel make issue where gen_code binary is copied to ../../../bin before it is created and the Makefile.am needs to explicitly list gen_code as a prerequisite for the 'all-local' target. This probably happens because slibtool is significantly faster than GNU libtool. * Additionally slibtool will output the gen_code binary to the .libs directory while slibtool will do so in the Makefile directory. The command needs to be invoked with $(LIBTOOL) --mode=execute to correctly copy the binary and not the slibtool wrapper script for the binary. * Lastly there is a workaround for a slibtool bug where the cp(1) command is wrapped in a shell script. Invoking the command directly with --mode=execute will result in slibtool dropping the destination argument which obviously does not work. While this workaround is far from ideal, it will be portable for GNU libtool, slibtool now and slibtool when the bug is fixed. Bug: https://bugs.gentoo.org/790770 Upstream-PR: https://sourceforge.net/p/ta-lib/patches/6/ Signed-off-by: orbea <orbea@riseup.net> Closes: https://github.com/gentoo/gentoo/pull/25457 Signed-off-by: Sam James <sam@gentoo.org> sci-libs/ta-lib/files/ta-lib-0.4.0-slibtool.patch | 92 +++++++++++++++++++++++ sci-libs/ta-lib/ta-lib-0.4.0-r1.ebuild | 41 ++++++++++ 2 files changed, 133 insertions(+)
*** Bug 808420 has been marked as a duplicate of this bug. ***
