From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 5EC9B3858C54 for ; Mon, 20 Nov 2023 15:23:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5EC9B3858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5EC9B3858C54 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700493793; cv=none; b=k9ZazQxbDPLgqbqSOQZslEaXG5GPq02258jv/ISXRUwx+cVMSjoX0b4j3MeX3TSPeRxBYcUphFCjDRrR9bOMpMgqFA5DQ/BYr/ZXaHiAgQ27XcOmLXtTd2iawWKbDj2vH3MHs28ixHfaH4mfU/fPaOelsQ5ru3itFXpd5uD13Tc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700493793; c=relaxed/simple; bh=TcG+6lhf0bi97n28k4LBWYulyI2jAgCWbq9aFLApIO8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=AUTv4pryrlqswGoMnX/kKGh+HXHO54la075R0N3lgFZeflW8JaKrSCj1HIryYCZdiG2OnKxsCCsaXfvQ4VRoO9sZB4sjRwqUqVhJjifDX7EPTO1TGfuOSfzGriLkz9/hdY0umPC+uIldB5KIw3YcYDBcSEzmSmCjHqdoBGhtD7I= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700493791; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=1JPQTnZIwIXZmN0vSsDcFrYVCl+aAm/GPujs4qfTV6M=; b=PKFPy+rX9hsigjUZhssfey+rssoBAHncNuWNbDg24GoSaIXpDyhqZqvmZaaoVXfjrfq/mP dyn8FNMDsJpDXmHMv2P9+B6E15e9+L5oMjFktPmqhDAR+oPKChSrIiF8sTpkbc+b3j7Zv8 itsvjsD9B9kpr0m+5bWLB9+hTsId3zc= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-249-rInWy6wbNduUcAeoP-hoHw-1; Mon, 20 Nov 2023 10:23:10 -0500 X-MC-Unique: rInWy6wbNduUcAeoP-hoHw-1 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-778b25af933so583866685a.3 for ; Mon, 20 Nov 2023 07:23:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700493789; x=1701098589; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1JPQTnZIwIXZmN0vSsDcFrYVCl+aAm/GPujs4qfTV6M=; b=CvMOoJfJLWyEYjydZE+d22V+sMgRZEgdTonSgOWEXa5OddLNREdzXXir+rQBhdx6qu 5rF8k2Pl86GgZiR0hwXFdZJmNHrOpQcWS9dQ67ukj9nXcQMv3PsTa2qNzyqgyB3HG9nK Pe1QS3KA1RHvX/PsvFEbLWV7h4e7Aynvhs6xj3pNkIgogfCy1BLIEI8f/iS+5+gF3Yxv zj4gJw+N6LPCVtQXp2AM2EDz7R2HCIvmxScFF9SNfWKfuAXzUdadJnQ+mMQRjrgME8/2 dS+18LZry+T6bEkVvchyPQQw4vzS0ikfPwaGIH5vAzBEi5CjXyZcZ7+8W4scZrFTV/6w gWfw== X-Gm-Message-State: AOJu0YwnGwCx5VboV4Lst4+a+qBbnUDoGb/u8iauMO0Q705fx5nzK6G2 pc9SXYG4qo+ad5oXSyuejcZNxF5L14p7wFIrBPURswES5lGM4u3HOx+KtASv0LotyVR+Yz40QQC VLER5gD4TRL7akpRXtGtbnugf0Q== X-Received: by 2002:a05:620a:60c4:b0:77a:25bd:e616 with SMTP id dy4-20020a05620a60c400b0077a25bde616mr6475736qkb.42.1700493789093; Mon, 20 Nov 2023 07:23:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IGy93+UsGGPKa2YX9BHp4v3YI0SD/A1T96Bksx66z5gibjp5eCKduvYUD0wnmIbx1HwOl1yqg== X-Received: by 2002:a05:620a:60c4:b0:77a:25bd:e616 with SMTP id dy4-20020a05620a60c400b0077a25bde616mr6475718qkb.42.1700493788679; Mon, 20 Nov 2023 07:23:08 -0800 (PST) Received: from [192.168.1.11] ([80.168.197.243]) by smtp.gmail.com with ESMTPSA id qf9-20020a05620a660900b007676f3859fasm2741318qkn.30.2023.11.20.07.23.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Nov 2023 07:23:08 -0800 (PST) Message-ID: <08886f47-a7c7-4a82-98b4-2d5588df25e2@redhat.com> Date: Mon, 20 Nov 2023 15:23:06 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Why GROUP(...) rather than INPUT(...) is used here? To: rednoah , binutils@sourceware.org References: <18014862.5f25.18bdcad7f2b.Coremail.rednoax@163.com> From: Nick Clifton Autocrypt: addr=nickc@redhat.com; keydata= xsFNBFm/2cUBEADkvRqMWfAryJ52T4J/640Av5cam9ojdFih9MjcX7QWFxIzJfTFYq2z+nb4 omdfZosdCJL2zGcn6C0AxpHNvxR9HMDkEyFHKrjDh4xWU+pH4z9azQEqJh331X7UzbZldqQo 16VkuVavgsTJaHcXm+nGIBTcUbl2oiTtHhmuaYxx6JTMcFjC7vyO5mLBw78wt52HBYweJ0Nj HBvvH/JxbAAULSPRUC61K0exlO49VFbFETQNG1hZTKEji95fPbre7PpXQ0ewQShUgttEE/J3 UA4jYaF9lOcZgUzbA27xTV//KomP0D30yr4e4EJEJYYNKa3hofTEHDXeeNgM25tprhBUMdbV RZpf2Keuk2uDVwc+EiOVri48rb1NU+60sOXvoGO6Ks81+mhAGmrBrlgLhAp8K1HPHI4MG4gH nrMqX2rEGUGRPFjC3qqVVlPm8H05PnosNqDLQ1Pf7C0pVgsCx6hKQB7Y1qBui7aoj9zeFaQg pYef+CEERIKEcWwrjaOJwK3pi9HFdxS0NNWYZj8HPzz/AsgTTQdsbulPlVq2SsctmOnL42CZ OCTppGYwl53CG/EqVY+UQBzFzJBaY8TJRFFYVEy5/HH4H11rMoZwqIkk71EOGU3X6mWlANRi kR3M4GhVITRzuaV69Fed+OeXcCmP94ASLfuhBR2uynmcHpBKpwARAQABzTtOaWNrIENsaWZ0 b24gKENoaWVmIEJpbnV0aWxzIE1haW50YWluZXIpIDxuaWNrY0ByZWRoYXQuY29tPsLBeAQT AQIAIgUCWb/ZxQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQE/zvid2ePE9cOxAA 3cX1bdDaTFttTqukdPXLCtD2aNwJos4vB4LYPSgugLkYaHIQH9d1NQPhS0TlUeovnFNESLaV soihv0YmBUCyL4jE52FRoTjE6fUhYkFNqIWN2HYwkVrSap2UUJFquRVoVbPkbSup8P+D8eyd BbdxsY6f+5E8Rtz5ibVnPZTib7CyqnFokJITWjzGdIP0Gn+JWVa6jtHTImWx1MtqiuVRDapU hrIoUIjf98HQn9/N5ylEFYQTw7tzaJNWeGUoGYS8+8n/0sNbuYQUU/zwMVY9wpJcrXaas6yZ XGpF/tua59t9LFCct+07YAUSWyaBXqBW3PKQz7QP+oE8yje91XrhOQam04eJhPIBLO88g6/U rdKaY7evBB8bJ76Zpn1yqsYOXwAxifD0gDcRTQcB2s5MYXYmizn2GoUm1MnCJeAfQCi/YMob R+c8xEEkRU83Tnnw3pmAbRU6OcPihEFuK/+SOMKIuV1QWmjkbAr4g9XeXvaN+TRJ9Hl/k1k/ sj+uOfyGIaFzM/fpaLmFk8vHeej4i2/C6cL4mnahwYBDHAfHO65ZUIBAssdA6AeJ+PGsYeYh qs6zkpaA2b0wT4f9s7BPSqi0Veky8bUYYY7WpjzDcHnj1gEeIU55EhOQ42dnEfv7WrIAXanO P8SjhgqAUkb3R88azZCpEMTHiCE4bFxzOmjOwU0EWb/ZxQEQALaJE/3u23rTvPLkitaTJFqK kwPVylzkwmKdvd2qeEFk1qys2J3tACTMyYVnYTSXy5EJH2zJyhUfLnhLp8jJZF4oU5QehOaJ PcMmzI/CZS1AmH+jnm6pukdZAowTzJyt4IKSapr+7mxcxX1YQ2XewMnFYpLkAA2dHaChLSU/ EHJXe3+O4DgEURTFMa3SRN/J4GNMBacKXnMSSYylI5DcIOZ/v0IGa5MAXHrP1Hwm1rBmloIc gmzexczBf+IcWgCLThyFPffv+2pfLK1XaS82OzBC7fS01pB/eDOkjQuKy16sKZX6Rt57vud4 0uE5a0lpyItC2P7u7QWL4yT5pMF+oS8bm3YWgEntV380RyZpqgJGZTZLNq2T4ZgfiaueEV4J zOnG2/QRGjOUrNQaYzKy5V127CTnRg4BYF/uLEmizLcI3O3U1+mEz6h48wkAojO1B6AZ8Lm+ JuxOW5ouGcrkTEuIG56GcDwMWS/Pw/vNsDyNmOCjy9eEKWJgmMmLaq59HpfTd8IOeaYyuAQH AsYt/zzKy0giMgjhCQtuc99E4nQE9KZ44DKsnqRabK9s3zYE3PIkCFIEZcUiJXSXWWOIdJ43 j+YyFHU5hqXfECM6rzKGBeBUGTzyWcOX6YwRM4LzQDVJwYG8cVfth+v4/ImcXR43D4WVxxBE AjKag02b+1yfABEBAAHCwV8EGAECAAkFAlm/2cUCGwwACgkQE/zvid2ePE/dqQ/6ApUwgsZz tps0MOdRddjPwz44pWXS5MG45irMQXELGQyxkrafc8lwHeABYstoK8dpopTcJGE3dZGL3JNz 1YWxQ5AV4uyqBn5N8RubcA8NzR6DQP+OGPIwzMketvVC/cbbKDZqf0uTDy3jP65OFhSkTEIy nYv1Mb4JJl3Sq+haUbfWLAV5nboSuHmiZE6Bz2+TjdoVkNwHBfpqxu6MlWka+P98SUcmY8iV hPy9QC1XFOGdFDFf1kYgHW27mFwds35NQhNARgftAVz9FZXruW6tFIIfisjr3rVjD9R8VgL7 l5vMr9ylOFpepnI6+wd2X1566HW7F1Zw1DIrY2NHL7kL5635bHrJY4n7o/n7Elk/Ca/MAqzd IZxz6orfXeImsqZ6ODn4Y47PToS3Tr3bMNN9N6tmOPQZkJGHDBExbhAi/Jp8fpWxMmpVCUl6 c85cOBCR4s8tZsvGYOjR3CvqKrX4bb8GElrhOvAJa6DdmZXc7AyoVMaTvhpq3gJYKmC64oqt 7zwIHwaCxTbP6C6oUp9ENRV7nHnXN3BlvIgCo4QEs6HkDzkmgYlCEOKBiDyVMSkPDZdsspa+ K4GlU2Swi/BDJMjtDxyo+K0M81LXXxOeRfEIfPtZ3ddxBKPva1uSsuz+pbN9d1JY8Ko5T/h1 6susi2ReUyNJEJaSnjO5z13TQ1U= In-Reply-To: <18014862.5f25.18bdcad7f2b.Coremail.rednoax@163.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_WEB,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi rednoah, > GROUP ( libgcc_s.so.1 -lgcc ) > > The "-lgcc" linked here is actually libgcc.a. "libgcc_s.so.1" is an elf > shared object so there is only one archive file "libgcc.a" in GROUP(...). > GROUP(...) equals to "--start-group ... --end-group" and it is to enclose > two or more archive files to search undefined symbols repeatedly. There > seems no need to uss it when there is only one archive file in it. Maybe > INPUT(...) is a better choice here? Well... there is a theoretical difference. The thing is, the GROUP construct means that if there is code in libgcc.a that needs functions provided by libgcc_s.so.1 then it will be included even if there are no other code that needs libgcc_s.so.1. Here is a rather contrived example: $ cat main.c extern void atexit (int); int __dso_handle; int main (void) { atexit (0); return 0; } $ cat /usr/lib64/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) ) I am running this test on my Fedora 38 box, so the libraries are slightly different from the ones you are using, but the test does show my first point which is that main.c does not call any functions in the shared C library (libc.so.6) but it does call a function in the static C library (libc_nonshared.a): So, if I compile and then link my program with the "libc.so" fake C library, everything works: $ gcc -c -fPIC main.c $ ld -e 0 main.o -L/usr/lib64 --as-needed -lc The GROUP command has caused the linker to deduce that the real shared C library is needed: $ ldd a.out linux-vdso.so.1 (0x00007fff6665e000) libc.so.6 => /lib64/libc.so.6 (0x000014fb0b800000) /lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x000014fb0b9f9000) But if I create an alternative version of libc.so that uses INPUT directives instead of a GROUP directive: $ cat libfred.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) INPUT(/lib64/libc.so.6) GROUP(/usr/lib64/libc_nonshared.a) INPUT(/lib64/ld-linux-x86-64.so.2) and then try to use it... $ ld -e 0 main.o -L/usr/lib64 --as-needed -L. -lfred ld: /usr/lib64/libc_nonshared.a(atexit.oS): in function `atexit': (.text+0xe): undefined reference to `__cxa_atexit' ...the link fails. Of course this can be fixed by moving the INPUT(/lib64/libc.so.6) to after the GROUP(/usr/lib64/libc_nonshared.a). But what if there is a function in libc.so.6 that needs code in libc_nonshared.a ? This is all mostly theoretical of course, since in real life these circumstances are very unlikely to occur. But why take the chance ? Using GROUP() works just as well as INPUT(), does not cost much more (since there is only one static library involved and it is not that big), and it means that the glibc maintainers do not have to worry about some future scenario where an unexpected dependency between the libraries does occur. Cheers Nick