From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id B1C681F5AE for ; Wed, 28 Apr 2021 14:40:27 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 74EA13AA0071; Wed, 28 Apr 2021 14:40:24 +0000 (GMT) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.218]) by sourceware.org (Postfix) with ESMTPS id 0FE9E3A7640F; Wed, 28 Apr 2021 14:40:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0FE9E3A7640F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=clisp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=bruno@clisp.org ARC-Seal: i=1; a=rsa-sha256; t=1619620820; cv=none; d=strato.com; s=strato-dkim-0002; b=q04LCXocyYH6kGwaTnshbwmcmQitK9a5iu2A/aCeEgMgu//mMUJ6vCVgX7UJ7jr/iZ 6HUKVbY8VX/v2XInC/368ZRLBy0qCZd9Q3uC0Wy40YDRYEg4sQL3TCas30OWVXl/F2HF M4g7swut/YvXRht/mgNufWTNMqdhDZZYwnyOODzeIIkZQw+PwK2EX7z8pBTUCrzdjCk+ o3RM+Hu7M9cqoJ6gOygWW9hbozoLjyb33pEyDpU/o1Ctft7zZGZpKOqdV2GllJ8j1cjq SfXpojFJxj4yHy6wi76HXZ4VEzRJ5W7YXa0VwUXNDHerZqLBUQvU8AQTMd03jtKIkNqQ 4Rww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1619620820; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=iRkdnSpPSRtuEFqNg+uAv+vhNukPDrwaYuW71/sYXaE=; b=c4eCqCIRrEEZ3NCiZwkv721azwIlfr/MZBF/k77cb9/KpT1+NUSQhSI3SwoSgTgX9g 0+8y7MbVm/Hw1e+gqFb0KtWiPcdut8KwH49kiI7jmi2vBGujR01CnTP3F1/DAz1RC0oG JLw+kz7bDLDLfKCWakE+9hmc6HUB8JH8VRRjavF+S8W+PPOLrxz271TZgGvVWldQwasr ge8TfZdahytSxdKiibrs/JBeIylxoRVVYzhupOQJCREnCnOWDLOC3LF2R/XJNySBnPgM XRDm+s3dgGjiICVUzlh7pG+wKm8ci+tLTgsak9T47pkuksbNp84vrj/VzTfvLUDfbKLZ Q94A== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1619620820; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=iRkdnSpPSRtuEFqNg+uAv+vhNukPDrwaYuW71/sYXaE=; b=i6qIxbkfLwmMp7eDZQrdIhdMp7wk4zETgvxOSRf1dL6t5nW8HLFIM7JdL4I/8aSZj9 ubPyBF3NxHGHW3RmOERgHF6aXiT1w38L+J8DXFlW6O752bl795lcROl1j/LvGW98KQys KzhunVm8bY4GLJaLJGweCiGf1HA2LOtLG6NAw+KzI1Ki0DNRaFQ9IHbhasbDzc2a4yZk sDXy5YAtH6eL3wIh6hxRCIpZd5OSWuGNjBUIoEGgXszCRcqQVgQEeHh2BpU2MbSkUIq7 wKroGDQc48jIeH1RZQzGL9MqdVp2prYYVvX5BhyVRQob975FbaWHrsmdA3KFuGy966Ky OWyg== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqf3z5NW" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.25.2 DYNA|AUTH) with ESMTPSA id 905ad3x3SEeI8Jv (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Wed, 28 Apr 2021 16:40:18 +0200 (CEST) From: Bruno Haible To: Florian Weimer Subject: Re: Undefined use of weak symbols in gnulib Date: Wed, 28 Apr 2021 16:40:18 +0200 Message-ID: <2800926.834q8TerIH@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-206-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <875z06lu3v.fsf@oldenburg.str.redhat.com> References: <87o8e0p92r.fsf@oldenburg.str.redhat.com> <19516512.8WduG5kV5J@omega> <875z06lu3v.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: , Cc: libc-alpha@sourceware.org, bug-gnulib@gnu.org, binutils@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" Hi Florian, Thank you for the details. > > In which situations will it crash? > > > > (a) when the code is in an executable, that gets linked with '-lpthread' > > and that does not use dlopen()? > > The pthread_mutexattr_gettype is defined, but also pthread_once and the > weak symbols, so there is no problem because the link editor doesn't do > funny things. > > > (b) when the code is in an executable, that gets linked WITHOUT > > '-lpthread' and that does not use dlopen()? > > Yes, it will crash or behave incorrectly on most architectures *if* > pthread_mutexattr_gettype becomes available for some reason. > > > (c) when the code is in an executable, that gets linked WITHOUT > > '-lpthread' and that does a dlopen("libpthread.so.X")? > > This will probably work because pthread_mutexattr_gettype is not rebound > to the definition. So, in the normal cases (link with '-lpthread', link without '-lpthread', and even with dlopen()), everything will work fine. The only problematic case thus is the the use of LD_PRELOAD. Right? I think few packages in a distro will be affected. And few users are using LD_PRELOAD on their own, because since the time when glibc started to use 'internal' calls to system calls where possible, there are not a lot of uses of LD_PRELOAD that still work. > > Under which conditions will it crash? > > > > ($) when the executable was built before glibc 2.34 and is run > > with glibc 2.34 ? > > Yes. > > > (%) when the executable is built against glibc 2.34 and is run > > with glibc 2.34 ? > > No. glibc 2.34 will behave as if an implicit -lpthread is present on > the linker program line. Good. This means a bullet-proof way for a distro to avoid the problem is to "rebuild the world" after importing glibc 2.34. > > And if it crashes, will setting the environment variable LD_DYNAMIC_WEAK [1] > > avoid the crash? > > No, it's unrelated. The crash or other undefined behavior is a > consequence of actions of the link editor and cannot be reverted at run > time. In other words, the problem is that - there are some/many binaries out there, that were produced by an 'ld' that did not anticipate the changes in glibc 2.34, and - these binaries have a problem not when run directly, but only when run with LD_PRELOAD. Right? Bruno