Failure snippet: """ guppy /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl # LANG=C ia64-unknown-linux-gnu-gcc -pipe -g -fdiagnostics-show-option -ggdb3 -O2 -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--as-needed -nostdlib -nostartfiles -static -o /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/elf/sln /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/csu/crt1.o /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/csu/crti.o `ia64-unknown-linux-gnu-gcc -pipe -g -fdiagnostics-show-option -ggdb3 -O2 -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--as-needed --print-file-name=crtbegin.o` /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/elf/sln.o /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/elf/static-stubs.o -Wl,-z,now -Wl,--start-group /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/libc.a -lgcc -Wl,--end-group `ia64-unknown-linux-gnu-gcc -pipe -g -fdiagnostics-show-option -ggdb3 -O2 -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--as-needed --print-file-name=crtend.o` /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/csu/crtn.o /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/libc.a(dl-support.o): in function `setup_vdso': /var/tmp/portage/sys-libs/glibc-2.31-r3/work/glibc-2.31/elf/setup-vdso.h:116:(.text+0x1322): relocation truncated to fit: GPREL22 against `.text' collect2: error: ld returned 1 exit status """
> /var/tmp/portage/sys-libs/glibc-2.31-r3/work/glibc-2.31/elf/setup-vdso.h:116:(.text+0x1322): relocation truncated to fit: GPREL22 against `.text' I think this short GPREL22 relocation comes from: """ $ objdump -d -S -r /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl /libc.a void _dl_non_dynamic_init (void) { 780: 08 48 49 18 80 05 [MMI] alloc r41=ar.pfs,18,12,0 ... static inline void __attribute__ ((always_inline)) setup_vdso (struct link_map *main_map __attribute__ ((unused)), struct link_map ***first_preload __attribute__ ((unused))) { #ifdef NEED_DL_SYSINFO_DSO if (GLRO(dl_sysinfo_dso) == NULL) 860: c2 70 04 00 00 24 [MII] (p06) mov r14=1 866: 00 00 00 02 80 c3 nop.i 0x0;; 86c: 01 00 00 84 (p07) mov r14=r0 870: 04 38 01 02 00 24 [MLX] addl r39=0,r1 870: GPREL22 _dl_sysinfo_dso 871: GPREL64I .rodata.str1.8+0x8 """ The _dl_sysinfo_dso reference is probably our candidate. I'm surprised it's not an LDXMOV / GPREL64I pair, but I don't remember specifics of loading local vs. global symbols. Checking source file.
gcc-9 generated full 64-bit relocation via MMI/MLX: 8c0: 08 28 01 02 00 24 [MMI] addl r37=0,r1 8c0: LTOFF22X _dl_sysinfo_dso 8c1: LTOFF22X _dl_verbose 8c6: 00 01 04 00 48 e0 addl r16=0,r1 8cc: 05 00 00 84 mov r47=r0 8d0: 05 70 01 00 00 21 [MLX] mov r46=r0 8d1: GPREL64I .rodata.str1.8+0x8 gcc-10 does local GPREL22: 870: 04 28 01 02 00 24 [MLX] addl r37=0,r1 870: GPREL22 _dl_sysinfo_dso 871: GPREL64I .rodata.str1.8+0x8 876: 00 00 00 00 00 60 movl r43=0x0 87c: 05 00 00 60 880: 09 80 00 02 00 24 [MMI] addl r16=0,r1 880: GPREL22 _dl_verbose I think it's a side-effect of -fno-common. gcc used not to know that global variable is defined in the same module and pessimistically assumed 64-bit offset. But now if attempts a module-local reference via GPREL22. At least we should be able to get an easy workaround.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f43c7cd9e5a92d784af5e21ba22083cdb70c0e51 commit f43c7cd9e5a92d784af5e21ba22083cdb70c0e51 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-05-15 23:11:54 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-05-15 23:12:14 +0000 sys-libs/glibc: avoid GPREL overflow on ia64, bug #723268 -fno-common had unintended side-effect to optimise more accesses to global variables as module-local via GPREL22 relocations. Unfortunately glibc is large enough to overflow GPREL22 offset. Let's add a -fcommon workaround back to pessimize code slightly that refers module-local globals. We'll need an equivalen of -fPIC to do it consistently. Bug: https://bugs.gentoo.org/723268 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-libs/glibc/glibc-2.30-r8.ebuild | 6 ++++++ sys-libs/glibc/glibc-2.31-r3.ebuild | 6 ++++++ sys-libs/glibc/glibc-9999.ebuild | 6 ++++++ 3 files changed, 18 insertions(+)
Slightly more performant workaround is to use -mno-sdata: // $ cat a.c int v; int read_v(void) { return v; } $ ia64-unknown-linux-gnu-gcc-10.1.0 -O2 -S a.c -o a-mno-sdata.S -mno-sdata $ ia64-unknown-linux-gnu-gcc-10.1.0 -O2 -S a.c -o a.S $ diff -y a.S a-mno-sdata.S read_v: read_v: .prologue .prologue .body .body > .mlx > nop 0 > movl r14 = @gprel(v#) > ;; .mmi .mmi nop 0 nop 0 addl r14 = @gprel(v#), gp | add r14 = r1, r14 nop 0 nop 0 ;; ;; That way we still avoid PLT dereference but use slightly larger 64-bit form of gprel. Given how small sdata for nowadays' programs maybe it's time to flip -mno-sdata on by default :)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8ec720b67f38952a4b9c6054c6d8ef0fc79d0343 commit 8ec720b67f38952a4b9c6054c6d8ef0fc79d0343 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-05-16 08:57:53 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-05-16 08:58:04 +0000 sys-libs/glibc: use -mno-sdata, not -fcommon, bug #723268 -fcommon generated PLT references and added double memory dereference. -mno-sdata is slightly more efficient as it still sees globals to be module local varilables and uses GPREL64 (instead of PLT indirection) and uses single memory dereference. Bug: https://bugs.gentoo.org/723268 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-libs/glibc/glibc-2.30-r8.ebuild | 3 ++- sys-libs/glibc/glibc-2.31-r3.ebuild | 3 ++- sys-libs/glibc/glibc-9999.ebuild | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-)
Looking now at why we overflow 4MB range, that sounds like a lot for mere .sbss/.sdata binary. Usually it takes 1-2KB. Looking at the precise error message: build-ia64-ia64-unknown-linux-gnu-nptl/libc.a(dl-support.o): in function `setup_vdso': glibc-2.31/elf/setup-vdso.h:116:(.text+0x1322): relocation truncated to fit: GPREL22 against `.text' collect2: error: ld returned 1 exit status it tells us that GPREL22 wants to encode an offset from 'gp' register (GP-REL-ative) to '.text' symbol (the very start of .text section). 'gp' normally points to start of '.got' section. Example layout for a hello world program: $ cat a.c int main(){} $ gcc -g a.c -o a $ gdb ./a (gdb) start Temporary breakpoint 1, main () at a.c:1 (gdb) print &main $1 = (int (*)()) 0x20000008000007f0 <main> (gdb) print (void*)$r1 $2 = (void *) 0x2000000800010ec0 Note: $r1 is way below .text. I think GPREL relocations are signed. Here is the section ordering (also match virtual address ordering): $ readelf -S a ... [12] .text PROGBITS 0000000000000640 00000640 00000000000003e0 0000000000000000 AX 0 0 64 ... [19] .data PROGBITS 0000000000010e30 00000e30 0000000000000004 0000000000000000 WA 0 0 4 ... [23] .got PROGBITS 0000000000010ec0 00000ec0 0000000000000040 0000000000000000 WAp 0 0 8 [24] .IA_64.pltoff PROGBITS 0000000000010f00 00000f00 0000000000000020 0000000000000000 WAp 0 0 16 [25] .sdata PROGBITS 0000000000010f20 00000f20 0000000000000010 0000000000000000 WAp 0 0 8 [26] .sbss NOBITS 0000000000010f30 00000f30 0000000000000008 0000000000000000 WAp 0 0 8 [27] .bss NOBITS 0000000000010f38 00000f30 0000000000000008 0000000000000000 WA 0 0 8 Note: the distance from .text to .got is as big as a whole '.text' and '.data' are. Ideally we should not use GPREL22 here. Let's see what code makes that decision and if we can convince it not to.
Looking at assembly file to see how GPREL instructions are usually encoded: $ ia64-unknown-linux-gnu-gcc -O2 dl-support.c -S -std=gnu11 -fgnu89-inline -O2 -fmerge-all-constants -frounding-math -fno-stack-protector -fmath-errno -ftls-model=initial-exec -U_FORTIFY_SOURCE -I../include -I/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/elf -I/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl -I../sysdeps/unix/sysv/linux/ia64 -I../sysdeps/ia64/nptl -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ia64/fpu -I../sysdeps/ia64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/float128 -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/ia64-unknown-linux-gnu/10.1.0/include -isystem /usr/lib/gcc/ia64-unknown-linux-gnu/10.1.0/include-fixed -isystem /usr/ia64-unknown-linux-gnu/usr/include -D_LIBC_REENTRANT -include /tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h -DPIC -DTOP_NAMESPACE=glibc -o /tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/elf/dl-support.S These are good 64-bit GPREL references into .rodata section: ... .L228: .mlx nop 0 movl r47 = @gprel(__PRETTY_FUNCTION__.1#) .section .rodata.str1.8 .align 8 __PRETTY_FUNCTION__.1: stringz "setup_vdso" Theese are good 22-bit GPREL references into .sbss: _dl_aux_init: .prologue .mmi alloc r16 = ar.pfs, 1, 12, 8, 0 .body ld8 r14 = [r32] addl r15 = @gprel(_dl_auxv#), gp ... .section .sbss .align 4 ... _dl_auxv: .skip 8 .global _dl_correct_cache_id# Let's assume _dl.*# are all in .sdata/.sbss and are small enough not to check them. The rest of gprel references are: We have 3 suspicious references: $ fgrep gprel elf/dl-support.S | fgrep -v 'movl ' | egrep -v '_dl.*#' (p7) addl r14 = @gprel(.LC1), gp addl r35 = @gprel(.LC17), gp (p7) addl r14 = @gprel(.LC1), gp .LC1/.LC17 looks like a good .sdata reference: $ fgrep -C2 'LC1:' elf/dl-support.S .sdata .align 8 .LC1: data8 .LC0+9 .align 8 .LC17: data8 unsecure_envvars.2#+275 Trying again to match against exact relocation.
Matching object file back to GPREL22: build-ia64-ia64-unknown-linux-gnu-nptl/libc.a(dl-support.o): in function `setup_vdso': glibc-2.31/elf/setup-vdso.h:116:(.text+0x1322): relocation truncated to fit: GPREL22 against `.text' collect2: error: ld returned 1 exit status objdump shows the following code around 0x1322 offset: $ objdump -d -r -S elf/dl-support.o 1300: 02 08 00 54 00 21 [MII] mov r1=r42 1302: GPREL22 _dl_nns GL(dl_nns) = 1; 1306: 10 09 00 00 48 e0 mov r17=1;; 130c: 01 08 00 90 addl r15=0,r1 if (GLRO(dl_sysinfo) == DL_SYSINFO_DEFAULT) 1310: 0a 70 00 02 00 24 [MMI] addl r14=0,r1;; 1310: GPREL22 _dl_sysinfo 1312: GPREL22 _dl_sysinfo_map GLRO(dl_sysinfo_map) = l; 1316: 00 88 3c 30 23 e0 st8 [r15]=r17 131c: 01 08 00 90 addl r15=0,r1 if (GLRO(dl_sysinfo) == DL_SYSINFO_DEFAULT) 1320: 0b 80 00 1c 18 10 [MMI] ld8 r16=[r14];; 1322: GPREL22 .text 1326: 00 08 3d 30 23 e0 st8 [r15]=r33 132c: 01 08 00 90 addl r15=0,r1;; GLRO(dl_sysinfo) = GLRO(dl_sysinfo_dso)->e_entry + l->l_addr; 1330: 0a 38 3c 20 06 f8 [MMI] cmp.eq p7,p6=r15,r16;; 1336: 01 01 9c 30 20 00 (p07) ld8 r16=[r39] 133c: 00 00 04 00 nop.i 0x0 1340: eb 88 00 42 18 d0 [MMI] (p07) ld8 r17=[r33];; 1346: 01 c1 40 00 42 00 (p07) adds r16=24,r16 134c: 00 00 04 00 nop.i 0x0;; 1350: e3 78 00 20 18 10 [MII] (p07) ld8 r15=[r16] 1356: 00 00 00 02 80 e3 nop.i 0x0;; 135c: f1 88 00 80 (p07) add r15=r15,r17;; 1360: e8 00 3c 1c 98 11 [MMI] (p07) st8 [r14]=r15 1366: 00 00 00 02 00 00 nop.m 0x0 136c: 00 00 04 00 nop.i 0x0 Grabbed a bit more to ease mapping back to source file. Now matching against .S file shows only 2 places: $ fgrep 'ld8 r16 = [r14]' elf/dl-support.S ld8 r16 = [r14] ld8 r16 = [r14] Looks about right: .L125: .mib mov r45 = r0 mov r44 = r33 br.call.sptk.many b0 = _dl_add_to_namespace_list# ;; .mii mov r1 = r42 addl r17 = 1, r0 ;; addl r15 = @gprel(_dl_nns#), gp .mmi addl r14 = @gprel(_dl_sysinfo#), gp ;; st8 [r15] = r17 addl r15 = @gprel(_dl_sysinfo_map#), gp .mmi ld8 r16 = [r14] # <<<------- here is our dereference. ;; st8 [r15] = r33 addl r15 = @gprel(_dl_sysinfo_break#), gp ;; I think '.text' is unexpected here (as if '_dl_sysinfo_break#' was lost) and it's probably a glibc bug. Compared to '_dl_nns#' / '_dl_sysinfo#' / '_dl_sysinfo_map#' global data symbols '_dl_sysinfo_break#' is an assemby-defined function. sysdeps/unix/sysv/linux/ia64/dl-sysdep.h:extern int _dl_sysinfo_break attribute_hidden; sysdeps/unix/sysv/linux/ia64/dl-sysdep.h:# define DL_SYSINFO_DEFAULT ((uintptr_t) &_dl_sysinfo_break) sysdeps/unix/sysv/linux/ia64/dl-sysdep.h: ".hidden _dl_sysinfo_break\n\t" \ sysdeps/unix/sysv/linux/ia64/dl-sysdep.h: ".proc _dl_sysinfo_break\n\t" \ sysdeps/unix/sysv/linux/ia64/dl-sysdep.h: "_dl_sysinfo_break:\n\t" \ sysdeps/unix/sysv/linux/ia64/dl-sysdep.h: ".endp _dl_sysinfo_break\n\t" \ This confuses gcc into building invalid global references.
The prototype mandling is intentional to avoid function descriptor indirection: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ia64/dl-sysdep.h;h=78fa6dd2c97d752d0d229ea1a33b98e5c1623cb6;hb=HEAD#l35 """ 32 #ifndef __ASSEMBLER__ 33 /* Don't declare this as a function---we want it's entry-point, not 34 it's function descriptor... */ 35 extern int _dl_sysinfo_break attribute_hidden; 36 # define DL_SYSINFO_DEFAULT ((uintptr_t) &_dl_sysinfo_break) 37 # define DL_SYSINFO_IMPLEMENTATION \ 38 asm (".text\n\t" \ 39 ".hidden _dl_sysinfo_break\n\t" \ 40 ".proc _dl_sysinfo_break\n\t" \ """ I guess that code has to work before dynamic relocations are set up and that is the reason to avoid function descriptors.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c6c63ec156e40e8b28724f2b49a8b0cf2ebf3033 commit c6c63ec156e40e8b28724f2b49a8b0cf2ebf3033 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-05-16 11:27:17 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-05-16 11:30:49 +0000 sys-libs/glibc: revert "use -mno-sdata, not -fcommon, bug #723268" The underying linker failure cause is not just an overflow but a functional difference in '_dl_sysinfo_break' symbol linkage. '_dl_sysinfo_break' is defined as a function in assembly but declared as a global 'common' variable. Making it non-common actually breaks sysinfo handler which is expected to be called without function descriptor indirection. As sysonfo handler is called before rtld processed it's own relocations. Let's revert back to -fcommon until we have better glibc fix. This reverts commit 8ec720b67f38952a4b9c6054c6d8ef0fc79d0343. Bug: https://bugs.gentoo.org/723268 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-libs/glibc/glibc-2.30-r8.ebuild | 3 +-- sys-libs/glibc/glibc-2.31-r3.ebuild | 3 +-- sys-libs/glibc/glibc-9999.ebuild | 3 +-- 3 files changed, 3 insertions(+), 6 deletions(-)
Created attachment 639630 [details, diff] glibc-2.31-ia64-fno-common.patch Testing glibc-2.31-ia64-fno-common.patch locally. It looks like the cleanest way to provide symbol hints to get GPREL64.
(In reply to Sergei Trofimovich from comment #11) > Created attachment 639630 [details, diff] [details, diff] > glibc-2.31-ia64-fno-common.patch > > Testing glibc-2.31-ia64-fno-common.patch locally. It looks like the cleanest > way to provide symbol hints to get GPREL64. Patch did not seem to break any vital tests. Proposed patch upstream as https://sourceware.org/pipermail/libc-alpha/2020-May/114028.html
Fixed in sys-libs/glibc-2.31-r6
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d99ab81692f0f04aa1421087c970ffd360163962 commit d99ab81692f0f04aa1421087c970ffd360163962 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-07-18 16:58:28 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-07-18 16:58:28 +0000 sys-libs/glibc: drop -fcommon on ia64 (fixed in code) Glibc patchset now contains 0100-Fix-miscompilation-on-ia64-s-gcc-10.patch to workaround invalid relocation on ia64. Bug: https://bugs.gentoo.org/723268 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-libs/glibc/glibc-2.31-r6.ebuild | 6 ------ sys-libs/glibc/glibc-9999.ebuild | 6 ------ 2 files changed, 12 deletions(-)
Is it expected to hit this issue with =sys-libs/glibc-2.32-r2? I'm unable to compile any kernel with genkernel, the latter complaining with: [CC] liblvm2cmd.so ia64-unknown-linux-gnu-gcc -shared -Wl,-soname,liblvm2cmd.so.2.02 \ -Os -pipe -fomit-frame-pointer -I/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/include -fPIC -Wl,--version-script,.export.sym -L../libdm -L../lib -L../libdaemon/client -L../daemons/dmeventd -o liblvm2cmd.so \ -Wl,-whole-archive liblvm2cmd.a -Wl,-no-whole-archive \ -llvm-internal ../base/libbase.a -ldevmapper-event -ldaemonclient -L/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/lib -ludev -ldl -L/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/lib -lblkid -ldevmapper -laio /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(vfprintf-internal.o): in function `printf_positional': (.text+0x1571): relocation truncated to fit: GPREL22 against symbol `__printf_arginfo_table' defined in __libc_freeres_ptrs section in /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-printf.o) (.text+0x16e2): relocation truncated to fit: GPREL22 against symbol `__printf_va_arg_table' defined in __libc_freeres_ptrs section in /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o) (.text+0x41c2): relocation truncated to fit: GPREL22 against symbol `__printf_va_arg_table' defined in __libc_freeres_ptrs section in /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o) /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(vfprintf-internal.o): in function `__vfprintf_internal': (.text+0x53b1): relocation truncated to fit: GPREL22 against symbol `__printf_va_arg_table' defined in __libc_freeres_ptrs section in /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o) collect2: error: ld returned 1 exit status
(In reply to Émeric Maschino from comment #15) > Is it expected to hit this issue with =sys-libs/glibc-2.32-r2? =sys-libs/glibc-2.32-r2 has a fix for it. > I'm unable to > compile any kernel with genkernel, the latter complaining with: That is probably a different issue. > [CC] liblvm2cmd.so > ia64-unknown-linux-gnu-gcc -shared -Wl,-soname,liblvm2cmd.so.2.02 \ > -Os -pipe -fomit-frame-pointer > -I/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/include -fPIC > -Wl,--version-script,.export.sym -L../libdm -L../lib -L../libdaemon/client > -L../daemons/dmeventd -o liblvm2cmd.so \ > -Wl,-whole-archive liblvm2cmd.a -Wl,-no-whole-archive \ > -llvm-internal ../base/libbase.a -ldevmapper-event -ldaemonclient > -L/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/lib -ludev -ldl > -L/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/lib -lblkid -ldevmapper > -laio > /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(vfprintf-internal. > o): in function `printf_positional': > (.text+0x1571): relocation truncated to fit: GPREL22 against symbol > `__printf_arginfo_table' defined in __libc_freeres_ptrs section in > /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-printf.o) > (.text+0x16e2): relocation truncated to fit: GPREL22 against symbol > `__printf_va_arg_table' defined in __libc_freeres_ptrs section in > /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o) > (.text+0x41c2): relocation truncated to fit: GPREL22 against symbol > `__printf_va_arg_table' defined in __libc_freeres_ptrs section in > /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o) > /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(vfprintf-internal. > o): in function `__vfprintf_internal': > (.text+0x53b1): relocation truncated to fit: GPREL22 against symbol > `__printf_va_arg_table' defined in __libc_freeres_ptrs section in > /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o) > collect2: error: ld returned 1 exit status Specifically it tries to link in static libc into a shared library. That looks very wrong.
Will then report. Against sys-kernel/genkernel?
That should be a good start.
(In reply to Sergei Trofimovich from comment #18) > That should be a good start. Done: bug #749957 for interested people.
Should this be marked as fixed per https://gitweb.gentoo.org/proj/toolchain/glibc-patches.git/commit/?id=35cb82bd164e19b0b37a90b1a62da71dd4ddd950 ?
