From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <eggert@cs.ucla.edu>
Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68])
 by sourceware.org (Postfix) with ESMTPS id 03F3F3858024;
 Tue, 27 Apr 2021 06:50:28 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 03F3F3858024
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=cs.ucla.edu
Authentication-Results: sourceware.org;
 spf=pass smtp.mailfrom=eggert@cs.ucla.edu
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3841B160152;
 Mon, 26 Apr 2021 23:50:28 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id 1tL1xzqxvS3y; Mon, 26 Apr 2021 23:50:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6229916015B;
 Mon, 26 Apr 2021 23:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id 04JhzXxVOzCH; Mon, 26 Apr 2021 23:50:27 -0700 (PDT)
Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com
 [172.91.119.151])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3A64D160152;
 Mon, 26 Apr 2021 23:50:27 -0700 (PDT)
Subject: Re: Undefined use of weak symbols in gnulib
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org, binutils@sourceware.org, bug-gnulib@gnu.org
References: <87o8e0p92r.fsf@oldenburg.str.redhat.com>
From: Paul Eggert <eggert@cs.ucla.edu>
Organization: UCLA Computer Science Department
Message-ID: <ad259dd6-6998-37a4-d893-12457c5a24fe@cs.ucla.edu>
Date: Mon, 26 Apr 2021 23:50:26 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <87o8e0p92r.fsf@oldenburg.str.redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: libc-alpha@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Apr 2021 06:50:30 -0000

On 4/26/21 10:53 PM, Florian Weimer via Libc-alpha wrote:
> This will become an urgent issue with glibc 2.34, which defines
> pthread_mutexattr_gettype unconditionally.  Certain gnulib modules will
> stop working until the binaries are relinked.

Thanks for mentioning this. But in what sense will the modules stop 
working? I'm a little lost.

glibc 2.34 also defines pthread_once unconditionally, right? So why 
doesn't code like this:

   if (pthread_mutexattr_gettype != NULL)
     pthread_once (control, callback);

continue to work in 2.34?