From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id DCBFF385C8B1 for ; Thu, 25 Aug 2022 15:04:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DCBFF385C8B1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x234.google.com with SMTP id v125so23635643oie.0 for ; Thu, 25 Aug 2022 08:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc; bh=OWP+Y5fVNfT78VCmGh5vw1gZJZr0ePb488a6Z1uUgzo=; b=dSIEF2PlD/gIc8FIu/+EyGL6cJBEaeoQlQF26IjMGn/fjO2xfuzoNOU/YOEb+F+Tuu l1oby38IrndQ9opQ6a8hgRG6Sz/GLTp/U2FO/w4fMIFE70fPa+GNZ7JjOrBbUsssTc6Q nLmjAbRy+Xo8lxYC2qZQrd+0/pxj+GYaHjEY5B+crzBvo5pkzGArdSOOpgXcVbr6b/yj CaQft2v/IFGOaU3zUbaH5V4t3hJFisSGy6jrDhRjVHc/kWY7nfVlS1KocuLIGV28Ajig FjUQGqMEtj4cmIyGhqcl4E9w48qu26Ku7hAdURZvHGxDUfPpjq6v+ZDr+bNawIk0WBSE UmUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=OWP+Y5fVNfT78VCmGh5vw1gZJZr0ePb488a6Z1uUgzo=; b=HYO/imboj7KexWi3VjDrR3ujVm20CbKCtRHoUniHlPVe5gpNQ3RONgEZRki0v8hDcP 0+gsKqPcdR4F1WfTd0ad9DKwslPTw4fZ4eurJt7WBZPGbvcU4fWedne8txzY+EsyjweO hXJX0EbYuJnmpbUAjwNUUhxaJ8WicTw71klbnDOOP3zY8JHlMLG9qqS2d0o4SinKDSNr Lzt41g6MxrY9DRdd4Qlx0jw780rbrQ5GN9BpbmijGmteK0WAeBM7yXFimQNZH36iU2hw 1SnYl4MDhileK8thf3dOfZAYjflBEz853cMr56d31TDGotysVLHb5tGgxA5+Y8w3LSst c7vA== X-Gm-Message-State: ACgBeo2m8U3+Zu4i/AgAoHz1t7QrI3JykMmHSR/vunW8ZY+rklMsnBq0 bTqQ9DX4hEdICutHLje2RX9LBIz8bNnDnQ== X-Google-Smtp-Source: AA6agR7j+qqxZVQVb/+1yp/M/+teEa6xUb4JDKU/pUi0Aj/x5f3pxS8Jv2oeMXNEU/n7p9wtRdzQIw== X-Received: by 2002:a05:6808:23c6:b0:344:ef9e:2039 with SMTP id bq6-20020a05680823c600b00344ef9e2039mr1945997oib.140.1661439873026; Thu, 25 Aug 2022 08:04:33 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:745e:786a:689c:f1e5:7517? ([2804:1b3:a7c0:745e:786a:689c:f1e5:7517]) by smtp.gmail.com with ESMTPSA id w7-20020aca6207000000b0034305ddc29dsm4765791oib.28.2022.08.25.08.04.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Aug 2022 08:04:32 -0700 (PDT) Message-ID: <85b5446e-f4a5-c398-fba1-711ca9aa66a9@linaro.org> Date: Thu, 25 Aug 2022 12:04:30 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.1.2 Subject: Re: [PATCH] Revert "Detect ld.so and libc.so version inconsistency during startup" Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org References: <87mtbsdfma.fsf@oldenburg.str.redhat.com> <28ca2aac-11a9-0a6f-6974-ba1104ab121a@linaro.org> <8735dkbe6w.fsf@oldenburg.str.redhat.com> <576e96ab-aedd-19d2-9909-94664c2356d0@linaro.org> <87y1vc9ycm.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87y1vc9ycm.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 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,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: On 25/08/22 11:44, Florian Weimer wrote: > * Adhemerval Zanella Netto: > >> On 25/08/22 11:17, Florian Weimer wrote: >>> * Adhemerval Zanella Netto: >>> >>>> On 25/08/22 03:03, Florian Weimer via Libc-alpha wrote: >>>>> This reverts commit 6f85dbf102ad7982409ba0fe96886caeb6389fef. >>>>> >>>>> Once this change hits the release branches, it will require relinking >>>>> of all statically linked applications before static dlopen works >>>>> again, for the majority of updates on release branches: The NEWS file >>>>> is regularly updated with bug references, so the __libc_early_init >>>>> suffix changes, and static dlopen cannot find the function anymore. >>>>> >>>>> While this ABI check is still technically correct (we do require >>>>> rebuilding & relinking after glibc updates to keep static dlopen >>>>> working), it is too drastic for stable release branches. >>>> >>>> Sounds reasonable, although this is a configure options not enabled by >>>> default. Maybe extend the notes on either documentation and release wiki >>>> to describe the pitfalls of this option? >>> >>> The hash suffix is always active, even without the configure option. So >>> no, we can't leave this in as an optional feature. >>> >> >> Can't we make it optional then iff the configure option is enable to a >> version different than an empty one? Basically making the default as is >> and if user adds --with-extra-version-id= to use the new scheme? >> >> I will change the GLIBC_PRIVATE abi, but I think it should be expected. > > Is anyone going to use this? The static dlopen breakage would be pretty > drastic. And we just found out that this commit (which has been > backported widely, I think) > > commit 2376944b9e5c0364b9fb473e4d8dabca31b57167 > Author: Stefan Liebler > Date: Wed Apr 13 14:36:09 2022 +0200 > > S390: Add new s390 platform z16. > > The new IBM z16 is added to platform string array. > The macro _DL_PLATFORMS_COUNT is incremented. > > _dl_hwcaps_subdir is extended by "z16" if HWCAP_S390_VXRS_PDE2 > is set. HWCAP_S390_NNPA is not tested in _dl_hwcaps_subdirs_active > as those instructions may be replaced or removed in future. > > tst-glibc-hwcaps.c is extended in order to test z16 via new marker5. > > A fatal glibc error is dumped if glibc was build with architecture > level set for z16, but run on an older machine. (See dl-hwcap-check.h) > > breaks the GLIBC_PRIVATE ABI, and it is not even detected by the hashing > I implemented. So I think the trade-offs for the hashing/fingerprinting > implemented in the way the existing commit does are just very bad: it > breaks many totally harmless updates, and does not even reliably detect > the problematic updates. Fair enough, I agree that breaking static dlopen sounds a big change.