[PATCH v2] libio: Properly link in libio functions in static binaries

Adhemerval Zanella adhemerval.zanella@linaro.org
Fri Aug 22 21:18:27 GMT 2025



> Em 22 de ago. de 2025, à(s) 16:39, H.J. Lu <hjl.tools@gmail.com> escreveu:
> 
> On Fri, Aug 22, 2025 at 12:34 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
>> 
>> 
>> 
>>> On 22/08/25 16:04, H.J. Lu wrote:
>>> On Fri, Aug 22, 2025 at 10:28 AM Xi Ruoyao <xry111@xry111.site> wrote:
>>>> 
>>>> On Thu, 2025-08-21 at 16:57 -0700, H.J. Lu wrote:
>>>>> commit 3020f72618e4f1d7338cd42b8bc7b2813e961b5a
>>>>> Author: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
>>>>> Date:   Tue Dec 27 18:11:43 2022 -0300
>>>>> 
>>>>>    libio: Remove the usage of __libc_IO_vtables
>>>>> 
>>>>> added
>>>>> 
>>>>> #define libio_static_fn_required(name) __asm (".globl " #name);
>>>>> 
>>>>> to link in libio functions in static binaries.  But there is no relocation
>>>>> in
>>>>>      .globl  _IO_file_open
>>>>> 
>>>>> and "strip --strip-unneeded" will remove such unreferenced symbols which
>>>>> breaks static binaries.  Redefine libio_static_fn_required to create a
>>>>> reference to the required function with
>>>>> 
>>>>> static __typeof (name) *const name##_p __attribute__((used)) = name;
>>>>> 
>>>>> This fixes BZ #33300.
>>>>> 
>>>>> Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
>>>> 
>>>> Again:
>>>> 
>>>> Tested-by: Xi Ruoyao <xry111@xry111.site>
>>>> 
>>>> --
>>>> Xi Ruoyao <xry111@xry111.site>
>>> 
>>> I checked it in after testing s390x-linux-gnu with build-many-glibcs.py.
>> 
>> 
>> I don't have a strong preference, and this fix seems fine; but Florian has
>> asked if we can't just use SHF_GNU_RETAIN along with attribute ((used)) here.
> 
> SHF_GNU_RETAIN is used to keep an unused section for --gc-sections while
> this one is to include an object from libc.a.  Even if the section
> with _IO_file_doallocate
> is marked with SHF_GNU_RETAIN, it won't be linked in without a reference to
> _IO_file_doallocate.
> 

Fair enough, thanks for the explanation.

> --
> H.J.


More information about the Libc-alpha mailing list