From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id 0BBFB3858D39 for ; Fri, 4 Mar 2022 18:49:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0BBFB3858D39 Received: by mail-oi1-x233.google.com with SMTP id z8so5391213oix.3 for ; Fri, 04 Mar 2022 10:49:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=mRuco1xe8aQm885lb+eFvSa2yQMcjpWsz2sIP0ZrRHs=; b=U76fPAoaaAQ/yZExnc9X2yEdTXvelPikFeRHiQQ0r3kYuXYOoMx3G1LFOmpMXRGPKo BiwfzPwdSYsmTooHugLxTzV4w8w9X/38/vN8tkxjAzAwcyx3vRUtzarOfvnAvXciF4Zh XJFC5a6VrZV/PZajQM6ZO0fpiDayA0zPbGKEwupj/2wv/8rYwF+IOOltVGn6irQKMRp5 ikT5YCC1smlS9LzmVOgHFAwNEMHb/GIMnLGShqTyhEPOxeIMhMTWF4CCdIngXRk6I1lE LUh6XToDw/N/3MYomrGap09lkUCT9u1cAKKy+EUNFX2E9qKwv3EZinzHGj8BYwFUscVb rc9A== X-Gm-Message-State: AOAM5328sLjcBUOcT99q3+n9I+sQAguTA0C0v0LZyfrfPL5EbdAnJ9R2 nxTKsg7F9EIHL25qCPHdwwofN0e2KvkGbw== X-Google-Smtp-Source: ABdhPJylu4CHp2ZOecV6L7l+cUYK7exEdhRd92obNJsLKnzLb+SGJcbZLhRyyY+rC6vTZm8tdZwrfg== X-Received: by 2002:a05:6808:118e:b0:2d4:6fe7:6bd7 with SMTP id j14-20020a056808118e00b002d46fe76bd7mr22700oil.146.1646419790439; Fri, 04 Mar 2022 10:49:50 -0800 (PST) Received: from ?IPV6:2804:431:c7ca:2dcb:a992:742c:8048:43bc? ([2804:431:c7ca:2dcb:a992:742c:8048:43bc]) by smtp.gmail.com with ESMTPSA id q13-20020a0568080ecd00b002d44f01f1d7sm2955157oiv.40.2022.03.04.10.49.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Mar 2022 10:49:49 -0800 (PST) Message-ID: <5d862936-6fa5-c38f-23bf-c73223a523b3@linaro.org> Date: Fri, 4 Mar 2022 15:49:47 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH] powerpc: Use FLAG_ELF_LIBC6 for 32-bit known libraries Content-Language: en-US To: "Lucas A. M. Magalhaes" , libc-alpha@sourceware.org, fweimer@redhat.com, tuliom@linux.ibm.com References: <20211022211201.983646-1-lamm@linux.ibm.com> <20211104181039.97106-1-lamm@linux.ibm.com> <20220302193048.laaynlw7k3dzcz67@workbox> From: Adhemerval Zanella In-Reply-To: <20220302193048.laaynlw7k3dzcz67@workbox> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2022 18:49:52 -0000 On 02/03/2022 16:30, Raoni Fassina Firmino wrote: > On Fri, Dec 03, 2021 at 11:51:29AM -0300, AL glibc-alpha wrote: >> >> >> On 04/11/2021 15:10, Lucas A. M. Magalhaes via Libc-alpha wrote: >>> In systems with more versions of the known libraries, i.e. on IBM >>> Advance Toolchain, ldconfig will order them incorrectly on ld.cache. >>> >>> The issue only occurs with 32-bit libraries that don't depend on libc or >>> libm. That's because process_elf32_file check if the elf depends on one >>> of the libraries at known_libs to select the elf flag. For example, as >>> libc.so.6 don't depend on itself or on libm it will be flagged as >>> FLAG_ELF instead of FLAG_ELF_LIBC6 as expected. >> >> Wouldn't be simpler to check if the DT_SONAME matches any on 'known_libs' after >> dynamic section parsing and set the appropriated flag on generic 'process_file'? > > But then it would touch every architecture, I think since this is only a > problem affecting powerpc (BE 32bits) I don't think it is worth touch > the generic code if will not help any other architecture. Which is not a bad idea, removing arch-specific code and make the ldconfig have a similar semantic interdependently of the ABI is a good move forward. > > >> (also powerpc SYSDEP_KNOWN_LIBRARY_NAMES seems redundant). > > Seems to be the same as every other arch except i386. Lookin at Lucas's > RFC for removal of libc.5 and libc.4 compatibility, maybe it being > diferent in i386 is just that it was never really used anymore, and so > never updated. I think it would be better to send this change along the the RPC to remove libc4/libc5 compatibility. I am already proposing dropping some support for old lib5/aout files [1], which Florian thinks it is ok, so I take that dropping all support for libc4/libc5 is a way forward. In fact, with libc4/libc5 removal I think this patch is not really required. [1] https://patchwork.sourceware.org/project/glibc/patch/20220304133801.1868553-4-adhemerval.zanella@linaro.org/