libtool: link: x86_64-pc-linux-gnu-g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/crtbeginS.o .libs/liblutok_la-c_gate.o .libs/liblutok_la-debug.o .libs/liblutok_la-exceptions.o .libs/liblutok_la-operations.o .libs/liblutok_la-stack_cleaner.o .libs/liblutok_la-state.o -llua -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib64/crtn.o -O2 -march=native -Wl,-O1 -Wl,--as-needed -Wl,-soname -Wl,liblutok.so.3 -o .libs/liblutok.so.3.0.0 /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib64/liblua.a(lauxlib.o): relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib64/liblua.a(lbaselib.o): relocation R_X86_64_PC32 against symbol `stdout@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib64/liblua.a(ldblib.o): relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib64/liblua.a(liolib.o): relocation R_X86_64_PC32 against symbol `stdin@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_hardened-libressl_test-20200126-104546 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-9.2.0 * Available Python interpreters, in order of preference: [1] python3.6 [2] python2.7 (fallback) repository: ==> /var/db/repos/gentoo/metadata/timestamp.chk <== Sun, 26 Jan 2020 18:26:13 +0000 emerge -qpvO dev-lua/lutok [ebuild N ] dev-lua/lutok-0.4-r2 USE="-test"
Created attachment 604870 [details] emerge-info.txt
Created attachment 604872 [details] dev-lua:lutok-0.4-r2:20200126-194244.log
Created attachment 604874 [details] emerge-history.txt
Created attachment 604876 [details] environment
Created attachment 604878 [details] etc.portage.tbz2
Created attachment 604880 [details] logs.tbz2
Created attachment 604882 [details] temp.tbz2
This seems like a problem with dev-lang/lua. Does /usr/lib64/liblua.so exist?
(In reply to Mike Gilbert from comment #8) > This seems like a problem with dev-lang/lua. Does /usr/lib64/liblua.so exist? mr-fox ~ # ls -l /usr/lib64/liblua.so* lrwxrwxrwx 1 root root 15 Jan 27 02:30 /usr/lib64/liblua.so -> liblua.so.5.1.5 lrwxrwxrwx 1 root root 15 Jan 27 02:30 /usr/lib64/liblua.so.5 -> liblua.so.5.1.5 -rwxr-xr-x 1 root root 190168 Jan 27 02:30 /usr/lib64/liblua.so.5.1.5
I can't reproduce the problem. I'm not sure why it is trying to use liblua.a instead of liblua.so on your system.
