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: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=unavailable autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 6C81D1F5AE for ; Fri, 30 Apr 2021 09:55:47 +0000 (UTC) Received: from localhost ([::1]:55066 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcPsA-0008NA-4f for normalperson@yhbt.net; Fri, 30 Apr 2021 05:55:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54264) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcPry-0008LM-8f for bug-gnulib@gnu.org; Fri, 30 Apr 2021 05:55:34 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:33131) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcPrv-0003LI-Px for bug-gnulib@gnu.org; Fri, 30 Apr 2021 05:55:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619776529; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wu4hLHzi4ZeeNq0F/0q5YoHLzMGhnzjd01LHmuKt4d0=; b=Usu+czbIboLpbwyV7CCKxzSuWb2XcfCGlDkkSs4ZDGC3dx/voFmHsgf1J2+JJspmWMgQ+L 7WNZr1NRCVT+sMyfg3TZzlPi5WUZ77pGkUynx1HiD0G+WITzE1jZYv6h2pjQFsPW/bVeOR pXFYkFOwZd6dpeV3jNxAcLc7T0sv1go= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-459-SCGvOmEYPve-J5PU5leHZw-1; Fri, 30 Apr 2021 05:55:26 -0400 X-MC-Unique: SCGvOmEYPve-J5PU5leHZw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7159218BA282; Fri, 30 Apr 2021 09:55:25 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-115-124.ams2.redhat.com [10.36.115.124]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C48C8579B1; Fri, 30 Apr 2021 09:55:23 +0000 (UTC) From: Florian Weimer To: Bruno Haible Subject: Re: Undefined use of weak symbols in gnulib References: <87o8e0p92r.fsf@oldenburg.str.redhat.com> <2800926.834q8TerIH@omega> <87sg3agv90.fsf@oldenburg.str.redhat.com> <1745276.bs2KPpY2O9@omega> Date: Fri, 30 Apr 2021 11:55:36 +0200 In-Reply-To: <1745276.bs2KPpY2O9@omega> (Bruno Haible's message of "Thu, 29 Apr 2021 17:15:23 +0200") Message-ID: <87sg3885bb.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Received-SPF: pass client-ip=216.205.24.124; envelope-from=fweimer@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.22, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion 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: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" * Bruno Haible: >> I spent today on coming up with a workaround in glibc. > > These are the workarounds I can see: > - Delay the planned changes in glibc by 5 years or so, to minimize > the number of binaries out there that would crash. (Probably not what > you want.) Nah, those binaries won't go away in just five years. > - Change glibc's ld.so to deal with the binaries that are out there > and that have been produced by existing binutils (with or without the > patches that H.J. Lu listed). This is what I've tried to implement: [RFC] elf: Implement filtering of symbols historically defined in libpthread > - Play tricks with the preprocessor, such as > '#define pthread_create pthread_create_in_libc'. (Probably not POSIX > compliant.) It doesn't solve the problem, even for new binaries. > - Make use of symbol versioning. Symbol versioning was invented to > allow making big changes to libc without breaking binary backward > compatibility. (I don't know about the interplay between weak and > versioned symbols.) If the symbol is weak and undefined at build time, there is no symbol version attached to it. My patch uses that to make sure the filtering does not happen on the fast path (because symbols bound to libc.so.6 usually have versions), but I don't think symbol versioning is all that useful in this context. Thanks, Florian