>>> Compiling source in /var/tmp/portage/dev-libs/xxhash-0.6.5/work/xxHash-0.6.5 ... make -j8 AR=x86_64-pc-linux-gnu-ar CC=x86_64-pc-linux-gnu-gcc x86_64-pc-linux-gnu-gcc -O2 -march=native -pipe -Wall -Wextra -Wcast-qual -Wcast-align -Wshadow -Wstrict-aliasing=1 -Wswitch-enum -Wdeclaration-after-statement -Wstrict-prototypes -Wundef -c -o xxhash.o xxhash.c x86_64-pc-linux-gnu-gcc -O2 -march=native -pipe -Wall -Wextra -Wcast-qual -Wcast-align -Wshadow -Wstrict-aliasing=1 -Wswitch-enum -Wdeclaration-after-statement -Wstrict-prototypes -Wundef -Wl,-O1 -Wl,--as-needed xxhash.o xxhsum.c -o xxhsum compiling static library compiling dynamic library 0.6.5 x86_64-pc-linux-gnu-gcc -O2 -march=native -pipe -Wall -Wextra -Wcast-qual -Wcast-align -Wshadow -Wstrict-aliasing=1 -Wswitch-enum -Wdeclaration-after-statement -Wstrict-prototypes -Wundef -Wl,-O1 -Wl,--as-needed -shared -fPIC xxhash.o -Wl,-O1 -Wl,--as-needed -shared -fPIC -Wl,-soname=libxxhash.so.0 -o libxxhash.so.0.6.5 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: xxhash.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status
You forgot to attach your emerge --info output?
To reproduce the failure it needs a compiler that does not default to PIC. 13.0 amd64 profile or gcc older than 6 would do. Fails for me with CC=gcc-5.4.0 the same way: $ LANG=C CC=gcc-5.4.0 CFLAGS=-O2 e xxhash-0.6.5.ebuild clean install >>> Compiling source in /tmp/portage/dev-libs/xxhash-0.6.5/work/xxHash-0.6.5 ... make --jobs=8 --load-average=8 AR=x86_64-pc-linux-gnu-ar CC=gcc-5.4.0 gcc-5.4.0 -O2 -Wall -Wextra -Wcast-qual -Wcast-align -Wshadow -Wstrict-aliasing=1 -Wswitch-enum -Wdeclaration-after-statement -Wstrict-prototypes -Wundef -c -o xxhash.o xxhash.c gcc-5.4.0 -O2 -Wall -Wextra -Wcast-qual -Wcast-align -Wshadow -Wstrict-aliasing=1 -Wswitch-enum -Wdeclaration-after-statement -Wstrict-prototypes -Wundef -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu xxhash.o xxhsum.c -o xxhsum compiling static library compiling dynamic library 0.6.5 gcc-5.4.0 -O2 -Wall -Wextra -Wcast-qual -Wcast-align -Wshadow -Wstrict-aliasing=1 -Wswitch-enum -Wdeclaration-after-statement -Wstrict-prototypes -Wundef -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -shared -fPIC xxhash.o -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -shared -fPIC -Wl,-soname=libxxhash.so.0 -o libxxhash.so.0.6.5 /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: xxhash.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: nonrepresentable section on output collect2: error: ld returned 1 exit status make: *** [Makefile:110: libxxhash.so.0.6.5] Error 1 make: *** Waiting for unfinished jobs....
Created attachment 546970 [details] emerge--info
So it's caused by newer Gentoo GCC specs doing these unspeakably horrific things in the background and by default?
It''s somewhat related to specs but the bug is missing -fPIC. The failure would happen on vanilla x86_64-gcc as well. -fPIC (or -fpic) is required to be passed as a compiler option when C shared library is built. It is to make library loadable at an arbitrary virtual address. Otherwise compiler generates slightly more efficient code. USE=pie for >=gcc-6 passes --enable-default-pie ./configure flag (it's an upstream feature, nothing Gentoo-specific). --enable-default-pie enables -fPIE by default (it's almost -fPIC WRT code generation). Thus it's a coincidence that package happens to built on amd64/17.0 profile without problems. For comparison x86/17.0 profile (or amd64/13.0 profile) does not do USE=pie by default and generates TEXTREL in xxhash as -fPIC is missing: (on x86) # emerge -v1 xxhash * QA Notice: The following files contain runtime text relocations ... * Please include the following list of files in your report: * TEXTREL usr/lib/libxxhash.so.0.6.5 ... * For more information, see: * * https://wiki.gentoo.org/wiki/Hardened/HOWTO_locate_and_fix_textrels ... * ERROR: dev-libs/xxhash-0.6.5::gentoo failed: * Aborting due to QA concerns: textrels
Filed upstream: https://github.com/Cyan4973/xxHash/issues/147 I will add a workaround (append-flags -fPIC) in the mean time.
This bug has been introduced by recent patches to the Makefile in commits 01e24f2cd0d3bea9dab9c6047648941d677dbcb6 and 173c62837c28971e2c0c3bbc038ec16fe4930b38 that used the same object file both for the executable and for shared and static libraries. As the package maintainer you can imagine I am not amused. Please ask me before making this kind of change. I have reverted both commits, as xxhash is such a tiny package that compiling the object file twice is not a big deal. I prefer to keep things as they are upstream, but if you want to add back the change, please make sure that this bug is not reintroduced.
(In reply to Guilherme Amadio from comment #7) > This bug has been introduced by recent patches to the Makefile in commits > 01e24f2cd0d3bea9dab9c6047648941d677dbcb6 and > 173c62837c28971e2c0c3bbc038ec16fe4930b38 that used the same object file both > for the executable and for shared and static libraries. As the package > maintainer you can imagine I am not amused. Please ask me before making this > kind of change. I have reverted both commits, as xxhash is such a tiny > package that compiling the object file twice is not a big deal. I prefer to > keep things as they are upstream, but if you want to add back the change, > please make sure that this bug is not reintroduced. It is a pretty big deal on HPPA where compiling the object file takes a very long time when compiler optimisation is enabled. Also, compiling object files has nothing to do with statically/dynamically loaded libraries. The upstream Makefile has more problems than the ones I solved, so reverting the patches instead of extending them was the wrong choice entirely. Perhaps injecting -fPIC into CFLAGS would have just done the trick?
(In reply to Jeroen Roovers from comment #8) > It is a pretty big deal on HPPA where compiling the object file takes a very > long time when compiler optimisation is enabled. Also, compiling object > files has nothing to do with statically/dynamically loaded libraries. If that had been explained to me in a bug report, I would not have reverted your changes. As I said above, you can reintroduce the changes you made (or I can do it), but of course that compiling object files has to do with statically/dynamically loaded libraries if these object files are part of the libraries. The problem is that -fPIC was only added to the linking step, but it needs to be added to both the compiling and linking steps for it to work. > The upstream Makefile has more problems than the ones I solved, > so reverting the patches instead of extending them was the wrong choice > entirely. > > Perhaps injecting -fPIC into CFLAGS would have just done the trick? I did not say the upstream Makefile is wonderful, but you did add a problem, and since I did not know why you needed the changes, I just reverted to fix it.
This was fixed by going back to the upstream Makefile. If compiling the object file twice (with -fPIC and without for the shared and static libraries) is still a problem, I think it's best to propose a change upstream to fix it.
