From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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) From: Florian Weimer To: Bruno Haible Cc: bug-gnulib@gnu.org, libc-alpha@sourceware.org, binutils@sourceware.org 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-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 09:55:32 -0000 * 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