control: clone -1 -2 control: retitle -2 binutils: generates conflicting sections .note.GNU-stack in x86_64-linux-gnu/crt1.o control: reassign -2 binutils control: found -2 2.45.50.20251209-1 control: found -2 2.45.90.20260125-1 control: block -1 by -2 control: reassign -1 libc6-dev control: affects -1 tcc
Hi, On 2026-01-27 10:04, Laurent Cheylus wrote: > Package: libc6 > Version: 2.42-10+b1 > Severity: important > > Dear Maintainer, > > with the latest version 2.42-10+b1 of libc6* package on Debian/testing amd64, > there is an issue to compile some C code with tcc compiler using > /usr/lib/x86_64-linux-gnu/crt1.o file. > > In this file, there is 2 conflicting sections for ".note.GNU-stack": one with > NOTE(7) type and one with PROGBITS(10) type. > > $ readelf -S /usr/lib/x86_64-linux-gnu/crt1.o > There are 15 section headers, starting at offset 0x370: > > Section Headers: > [Nr] Name Type Address Offset > Size EntSize Flags Link Info Align > [ 0] NULL 0000000000000000 00000000 > 0000000000000000 0000000000000000 0 0 0 > [ 1] .text PROGBITS 0000000000000000 00000040 > 0000000000000031 0000000000000000 AX 0 0 16 > [ 2] .rela.text RELA 0000000000000000 00000290 > 0000000000000030 0000000000000018 I 12 1 8 > [ 3] .eh_frame PROGBITS 0000000000000000 00000078 > 000000000000005c 0000000000000000 A 0 0 8 > [ 4] .rela.eh_frame RELA 0000000000000000 000002c0 > 0000000000000030 0000000000000018 I 12 3 8 > [ 5] .data PROGBITS 0000000000000000 000000d4 > 0000000000000004 0000000000000000 WA 0 0 1 > [ 6] .bss NOBITS 0000000000000000 000000d8 > 0000000000000000 0000000000000000 WA 0 0 1 > [ 7] .note.GNU-stack NOTE 0000000000000000 000000d8 > 0000000000000000 0000000000000000 0 0 1 > [ 8] .note.gnu.pr[...] NOTE 0000000000000000 000000d8 > 0000000000000020 0000000000000000 A 0 0 8 > [ 9] .note.ABI-tag NOTE 0000000000000000 000000f8 > 0000000000000020 0000000000000000 A 0 0 4 > [10] .note.GNU-stack PROGBITS 0000000000000000 00000118 > 0000000000000000 0000000000000000 0 0 1 > [11] .rodata.cst4 PROGBITS 0000000000000000 00000118 > 0000000000000004 0000000000000004 AM 0 0 4 > [12] .symtab SYMTAB 0000000000000000 00000120 > 0000000000000108 0000000000000018 13 3 8 > [13] .strtab STRTAB 0000000000000000 00000228 > 0000000000000067 0000000000000000 0 0 1 > [14] .shstrtab STRTAB 0000000000000000 000002f0 > 000000000000007e 0000000000000000 0 0 1 > Key to Flags: > W (write), A (alloc), X (execute), M (merge), S (strings), I (info), > L (link order), O (extra OS processing required), G (group), T (TLS), > C (compressed), x (unknown), o (OS specific), E (exclude), > D (mbind), l (large), p (processor specific) Thanks, this happens when glibc is built with binutils >= 2.45.50.20260119-1, and it's not related to a glibc change. There is nothing we can do on the glibc side besides a rebuild against a fixed binutils version, so cloning and reassigning the bug to binutils. > See this thread on tinycc-devel ML for reproduction and further analysis > https://lists.nongnu.org/archive/html/tinycc-devel/2026-01/msg00029.html Thanks for the link. Could you tell me who has been informed on the "official Debian IRC channel"? If someone already investigated the issue it would avoid redoing the same work. > On my Debian/testing (amd64), binutils installed version = > 2.45.50.20251209-1+b1 FYI, libc6-dev 2.42-10 has been built with binutils 2.45.50.20251209-1+b1 while libc6-dev 2.42-10+b1 has been built with binutils 2.45.50.20260119-1. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
