Summary: | games-emulation/mupen64plus-ui-console-2.5 : /.../ld: _obj/cheat.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Michał Górny <mgorny> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugs, emily, saintdev, theonesleepymario, toolchain |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 642232 | ||
Attachments: |
emerge-info.txt
emerge-history.txt environment etc.portage.tbz2 games-emulation:mupen64plus-ui-console-2.5:20170616-085520.log temp.tbz2 Build.log |
Description
Toralf Förster
2017-06-18 14:33:06 UTC
Created attachment 477014 [details]
emerge-info.txt
Created attachment 477016 [details]
emerge-history.txt
Created attachment 477018 [details]
environment
Created attachment 477020 [details]
etc.portage.tbz2
Created attachment 477022 [details]
games-emulation:mupen64plus-ui-console-2.5:20170616-085520.log
Created attachment 477024 [details]
temp.tbz2
The exact same problem emerging here with gcc-7.2 (on a 17.0 profile). just to be sure:
--------------------------------------------------------------------------------
>>> Compiling source in /var/tmp/portage/games-emulation/mupen64plus-ui-console-2.5/work/mupen64plus-ui-console-src-2.5 ...
make -j5 -C projects/unix UNAME=Linux V=1 CROSS_COMPILE=x86_64-pc-linux-gnu- CC=x86_64-pc-linux-gnu-gcc CXX=x86_64-pc-linux-gnu-g++ PKG_CONFIG=x86_64-pc-linux-gnu-pkg-config OPTFLAGS= PREFIX=/usr LIBDIR=/usr/lib64 LDCONFIG=: INSTALL_STRIP_FLAG= 'SDL_CFLAGS=-D_REENTRANT -I/usr/include/SDL2' SDL_LDLIBS=-lSDL2 HOST_CPU=x86_64 all
make: Entering directory '/var/tmp/portage/games-emulation/mupen64plus-ui-console-2.5/work/mupen64plus-ui-console-src-2.5/projects/unix'
x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wall -ffast-math -fno-strict-aliasing -I../../src -pthread -fno-PIE -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/mupen64plus -MD -MP -c -o _obj/cheat.o ../../src/cheat.c
x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wall -ffast-math -fno-strict-aliasing -I../../src -pthread -fno-PIE -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/mupen64plus -MD -MP -c -o _obj/compare_core.o ../../src/compare_core.c
x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wall -ffast-math -fno-strict-aliasing -I../../src -pthread -fno-PIE -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/mupen64plus -MD -MP -c -o _obj/core_interface.o ../../src/core_interface.c
x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wall -ffast-math -fno-strict-aliasing -I../../src -pthread -fno-PIE -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/mupen64plus -MD -MP -c -o _obj/main.o ../../src/main.c
x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wall -ffast-math -fno-strict-aliasing -I../../src -pthread -fno-PIE -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/mupen64plus -MD -MP -c -o _obj/plugin.o ../../src/plugin.c
x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wall -ffast-math -fno-strict-aliasing -I../../src -pthread -fno-PIE -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/mupen64plus -MD -MP -c -o _obj/osal_dynamiclib_unix.o ../../src/osal_dynamiclib_unix.c
x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wall -ffast-math -fno-strict-aliasing -I../../src -pthread -fno-PIE -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/mupen64plus -MD -MP -c -o _obj/osal_files_unix.o ../../src/osal_files_unix.c
x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wall -ffast-math -fno-strict-aliasing -I../../src -pthread -fno-PIE -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/mupen64plus -MD -MP -Wl,-O1 -Wl,--as-needed _obj/cheat.o _obj/compare_core.o _obj/core_interface.o _obj/main.o _obj/plugin.o _obj/osal_dynamiclib_unix.o _obj/osal_files_unix.o -pthread -ldl -lSDL2 -o mupen64plus
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/cheat.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/compare_core.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/core_interface.o: relocation R_X86_64_32 against symbol `CoreHandle' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/main.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/plugin.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/osal_dynamiclib_unix.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/osal_files_unix.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/cheat.o: warning: relocation against `free@@GLIBC_2.2.5' in readonly section `.text'
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: *** [Makefile:316: mupen64plus] Error 1
make: Leaving directory '/var/tmp/portage/games-emulation/mupen64plus-ui-console-2.5/work/mupen64plus-ui-console-src-2.5/projects/unix'
Exactly the same error under gcc 6.4.0 . Gentoo profile is 17.0. Does the "recompile with -fPIC" mean to recompile it with -fPIC file (like under package.env) or something else? I tried it but it didn't work (same error over and over again). Created attachment 509888 [details]
Build.log
A user by the name of "username234" helped me out on gentoo's official irc (#gentoo on freenode). He asked to me to create a custom repository with a modified ebuild from https://github.com/nvinson/nuntoo/tree/master/games-emulation/mupen64plus-ui-console mupen64plus compiled with no errors. I’m pretty sure this should block bug 642232. I rebuilt world after upgrading to GCC 6 before profile 17.0 became stable, and this package installed fine then, which means this bug was introduced by PIE, not GCC 6. I can’t edit the bug metadata though, so perhaps someone who can could add that relationship? As suggested by comment #11 by NaniBot PIE=1 should do the trick from the initial set of ebuild I sent through the bugtracker: #482614 IUSE="debug +pic" ... OPTS="${OPTS} PIE=$(use pic && echo 1 || echo 0)" maybe would it have prevented this bug report to be blocker and the pain to maintain own overlay for some users (at least nvinson) ;) @toolchain, it seems that upstream is taking PIC/PIE as boolean. For shared libs, they're passing -fPIC on amd64 and -fno-PIC on x86. For executables, they default to -fno-PIE but support -fPIE. Now, given the new profiles: a. Do we want explicit -fno-PIC on x86 at all? Or should I strip that and just use compiler default there? b. Do we want to play with -fPIE/-fno-PIE at all? Or should I strip that and just use compiler default? (In reply to Michał Górny from comment #14) > @toolchain, it seems that upstream is taking PIC/PIE as boolean. For shared > libs, they're passing -fPIC on amd64 and -fno-PIC on x86. For executables, > they default to -fno-PIE but support -fPIE. > > Now, given the new profiles: > > a. Do we want explicit -fno-PIC on x86 at all? Or should I strip that and > just use compiler default there? > > b. Do we want to play with -fPIE/-fno-PIE at all? Or should I strip that and > just use compiler default? I'd strip and use compiler default in both cases (assuming the result works as expected). How severe would it be to strip just b., and leave a. as-is? I don't really feel like patching 10 packages unnecessarily, especially if someone is going to complain to me afterwards that I've destroyed the performance of his x86 system. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b2cea88960f84014b4e7d58b2f8246fda86987d5 commit b2cea88960f84014b4e7d58b2f8246fda86987d5 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-01-06 20:54:47 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-01-06 20:59:31 +0000 games-emulation/mupen64plus-ui-console: Remove -fno-PIE to fix build Remove the Makefile code responsible for appending -fPIE/-fno-PIE to ensure that the compiler defaults are respected, and the package is built correctly and consistently. Closes: https://bugs.gentoo.org/622122 .../mupen64plus-ui-console/mupen64plus-ui-console-2.5.ebuild | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) |