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=-4.0 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 47BDD1F466 for ; Tue, 28 Jan 2020 13:58:43 +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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=TB6fCexFavI80nJoGW8ZAVxccp8O78tYn4KrwSuhak1 cBc2uY/CFpOTVl5pIQPfpLeT8HcsuJAywSzM6EesrcGF4E5dRyajS4VQkTG7Tlsl 5XE8QODJjCyMUmfPZRXsDpylnhJ+KscYAsSsq6hwF2s6BrOrS9LnD0eqCgwVVAc0 = 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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; s=default; bh=4lDhgMEMxKdLasOSdGMydpv+hwI=; b=ce/YmcVynZJ72/5o3 uVGEUlCi/tKvCh52D5vrrXv3eGXBkIFG3NYroT6KD1lNn4yc98PYxjRh8M7p+DLw vPC0sc12CNqZEjuqRYoA3FOGX2uwfX673735lhV+a0QuhhZ8Po7ma6UHXDQGuBwy 3nGnxwFO1zRg0HtHjc+JjcoMgE= Received: (qmail 104325 invoked by alias); 28 Jan 2020 13:58:40 -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 104317 invoked by uid 89); 28 Jan 2020 13:58:40 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-delivery-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580219917; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nv4MDU7YMh3BqbLUPY77w1yLWqRbdgiz/lDdhMwE9/E=; b=SeVW5B4tQGfp2i/RRAPOLT3hbL+Npy+cAgt3Ppu0Y2sWjIK/U9T+OKraB5OFCmZCoIAJbM pbXnLuoFnW2vfovUEtW8rgqy9a1bXBTpq3qd1g0z2Sk/v7aunwWpGnEy+DZ0Gm9LF7hJkq HKKUhsQzWdBIWXGJbQlOmhg7j3LzxcA= From: Florian Weimer To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Subject: Re: Removing internal symbols References: <20200114185255.25813-1-samuel.thibault@ens-lyon.org> <20200114185255.25813-3-samuel.thibault@ens-lyon.org> <20200121212850.ufsmja7evi3bhwjx@function> <20200127215535.b5azfecvkmeuf7at@function> Date: Tue, 28 Jan 2020 14:58:30 +0100 In-Reply-To: (Adhemerval Zanella's message of "Tue, 28 Jan 2020 09:56:38 -0300") Message-ID: <878slrd6nt.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable * Adhemerval Zanella: > On 27/01/2020 18:55, Samuel Thibault wrote: >> Hello, >>=20 >> Expanding the subject a bit to catch more opinions on this: >>=20 >> 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=20 >>>> libpthread exported symbols is the correct solution.=20 >>>> >>>> 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?=20 >>> >>> _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. > > I think it might be fine in this case, assuming there is no external > linkage possible with header redirection. It is still a ABI break, but > if an application is using such symbol it is abusing the API. I don't have any ABI tooling for Hurd. But on GNU/Linux, GNU packages often use internal APIs of other GNU packages, without much coordination (probably assuming that's okay because it's all GNU). For glibc, we try to tell developers not to do that, but it's an ongoing effort and very much incomplete at this point. Thanks, Florian