Bug 706540 – dev-lua/lutok-0.4-r2 : /.../ld: /.../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

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description Toralf Förster 2020-01-26 19:51:15 UTC]

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"

[Comment 1 Toralf Förster 2020-01-26 19:51:17 UTC]

Created attachment 604870 [details]
emerge-info.txt

[Comment 2 Toralf Förster 2020-01-26 19:51:20 UTC]

Created attachment 604872 [details]
dev-lua:lutok-0.4-r2:20200126-194244.log

[Comment 3 Toralf Förster 2020-01-26 19:51:23 UTC]

Created attachment 604874 [details]
emerge-history.txt

[Comment 4 Toralf Förster 2020-01-26 19:51:26 UTC]

Created attachment 604876 [details]
environment

[Comment 5 Toralf Förster 2020-01-26 19:51:29 UTC]

Created attachment 604878 [details]
etc.portage.tbz2

[Comment 6 Toralf Förster 2020-01-26 19:51:32 UTC]

Created attachment 604880 [details]
logs.tbz2

[Comment 7 Toralf Förster 2020-01-26 19:51:34 UTC]

Created attachment 604882 [details]
temp.tbz2

[Comment 8 Mike Gilbert 2020-02-26 22:04:31 UTC]

This seems like a problem with dev-lang/lua. Does /usr/lib64/liblua.so exist?

[Comment 9 Toralf Förster 2020-02-26 22:06:53 UTC]

(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

[Comment 10 Mike Gilbert 2020-02-26 22:20:58 UTC]

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.