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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 5E3271F5AE for ; Fri, 30 Apr 2021 09:55:35 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5DD65385481F; Fri, 30 Apr 2021 09:55:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5DD65385481F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619776534; bh=wu4hLHzi4ZeeNq0F/0q5YoHLzMGhnzjd01LHmuKt4d0=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=HjVjIzsjzOnlnm0B8bIhAqSocinf6FMz1+UuHS0NZrpPBQxuI0mQQW/NlBvoOWrGw gf0jUrXb3exontNy8vfE5p0ha+yOTkJZwINJ6M/+dPXyCpnSsD0e/5o1E29AHlfbew P74rHO9UANg7BQIc99DqplZP+5jkUpsaoQf/K7xU= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id D8C593858039 for ; Fri, 30 Apr 2021 09:55:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D8C593858039 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) 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 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: libc-alpha@sourceware.org, bug-gnulib@gnu.org, binutils@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" * 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