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: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (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 569951F466 for ; Mon, 27 Jan 2020 21:57:58 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=KHo+ ghwe0TY+UCN2+JzCOWxFO9/L9fjNzhYQeBtcbHxcRQQviKIUxkwYvbS18xYHJxs/ 9gxFTokkY04I+wygvZWyuQNthq9UHX9l9uknEF4nH0xbGIYqmc/tEk5M2FS2KbZp 9VeI3eS+xt69npZn4oLg+PoplGEohw3WIpczezE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=kqSx/0a75t Z88eRcgiBuU/13W9k=; b=LDgyuILPw3tLNWs5lJuBXsB5dujIyOvah+x6pV9qFe llnNPHJaLGeGlcI606sFm9hIHlYtEl2iWuUuH3Dl97MNO22Hs9F6hJX2oZ1ibUE1 PoIx+3j+9LdIIMr35Ys8YmbejBxjwYgRsR2awoPxsN8EwPaw1qJOCthVHcLMjV1g E= Received: (qmail 86228 invoked by alias); 27 Jan 2020 21:57:55 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 86216 invoked by uid 89); 27 Jan 2020 21:57:55 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: hera.aquilenet.fr Date: Mon, 27 Jan 2020 22:55:35 +0100 From: Samuel Thibault To: libc-alpha@sourceware.org Subject: Removing internal symbols (Was: htl: Rename _pthread_mutex_init/destroy to __pthread_mutex_init/destroy) Message-ID: <20200127215535.b5azfecvkmeuf7at@function> References: <20200114185255.25813-1-samuel.thibault@ens-lyon.org> <20200114185255.25813-3-samuel.thibault@ens-lyon.org> <20200121212850.ufsmja7evi3bhwjx@function> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200121212850.ufsmja7evi3bhwjx@function> User-Agent: NeoMutt/20170609 (1.8.3) Hello, Expanding the subject a bit to catch more opinions on this: Samuel Thibault, le mar. 21 janv. 2020 22:28:50 +0100, a ecrit: > Adhemerval Zanella, le ven. 17 janv. 2020 17:40:09 -0300, a ecrit: > > > diff --git a/sysdeps/mach/hurd/i386/libpthread.abilist b/sysdeps/mach/hurd/i386/libpthread.abilist > > > index 0ede90859c..cda8755960 100644 > > > --- a/sysdeps/mach/hurd/i386/libpthread.abilist > > > +++ b/sysdeps/mach/hurd/i386/libpthread.abilist > > > @@ -14,8 +14,6 @@ GLIBC_2.12 _cthread_init_routine D 0x4 > > > GLIBC_2.12 _cthreads_flockfile F > > > GLIBC_2.12 _cthreads_ftrylockfile F > > > GLIBC_2.12 _cthreads_funlockfile F > > > -GLIBC_2.12 _pthread_mutex_destroy F > > > -GLIBC_2.12 _pthread_mutex_init F > > > GLIBC_2.12 _pthread_mutex_lock F > > > GLIBC_2.12 _pthread_mutex_trylock F > > > GLIBC_2.12 _pthread_mutex_unlock F > > > > I understand this change is follow Linux internal implementation > > and make mtx_init.c generic, but I don't think changing hurd > > libpthread exported symbols is the correct solution. > > > > Since the symbol won't be used anymore I think we can move to > > a compat symbol, something like: > > > > +strong_alias (__pthread_mutex_init, pthread_mutex_init); > > +hidden_def (__pthread_mutex_init) > > +#if SHLIB_COMPAT (libpthread, GLIBC_2_12, GLIBC_2_31) > > +compat_symbol (libpthread, __pthread_mutex_init, _pthread_mutex_init, GLIBC_2_12); > > +#endif > > But do we need to keep the compat symbols at all? > > _pthread_mutex_lock has never been exposed in a .h file, it should have > gotten version GLIBC_PRIVATE actually since it's only used between > libc.so and libpthread.so. Samuel