From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.emacs.bugs Subject: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90 Date: Mon, 20 Jun 2016 12:15:40 +0200 Message-ID: References: <57660B39.5080909@cs.ucla.edu> <5767B146.30902@cs.ucla.edu> <10c68790-0574-d3bd-752f-f5562ebf9fcb@redhat.com> <5767BFC2.3090504@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1466417797 8976 80.91.229.3 (20 Jun 2016 10:16:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 10:16:37 +0000 (UTC) Cc: 23760@debbugs.gnu.org To: Paul Eggert , Jan =?UTF-8?Q?Syn=C3=A1=C4=8Dek?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 20 12:16:27 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bEwFe-0004ry-CI for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2016 12:16:18 +0200 Original-Received: from localhost ([::1]:42464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEwFY-0002jl-Lh for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2016 06:16:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEwFS-0002Wo-Lm for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 06:16:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEwFO-0000u7-Ir for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 06:16:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEwFO-0000tr-FZ for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 06:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bEwFO-0006w8-48 for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 06:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Florian Weimer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Jun 2016 10:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23760 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23760-submit@debbugs.gnu.org id=B23760.146641775326648 (code B ref 23760); Mon, 20 Jun 2016 10:16:02 +0000 Original-Received: (at 23760) by debbugs.gnu.org; 20 Jun 2016 10:15:53 +0000 Original-Received: from localhost ([127.0.0.1]:47112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEwFF-0006vk-5U for submit@debbugs.gnu.org; Mon, 20 Jun 2016 06:15:53 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:34012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEwFB-0006vU-71 for 23760@debbugs.gnu.org; Mon, 20 Jun 2016 06:15:51 -0400 Original-Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E972B80F6D; Mon, 20 Jun 2016 10:15:42 +0000 (UTC) Original-Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5KAFeH0026562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jun 2016 06:15:41 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 In-Reply-To: <5767BFC2.3090504@cs.ucla.edu> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 20 Jun 2016 10:15:43 +0000 (UTC) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:119820 Archived-At: On 06/20/2016 12:04 PM, Paul Eggert wrote: > On 06/20/2016 11:21 AM, Florian Weimer wrote: >> >> The usual mechanism for deprecation and removal of an API does not >> work if the symbol is interposed because it will be unversioned, and >> unversioned symbols preempt versioned symbols. As a result, even if >> the symbol is a compat symbol, you can produce new binaries which use >> the removed API. >> > > True, but in this particular case Emacs is replacing malloc as well as > __malloc_initialize_hook etc., so I don't see a problem. Although new > Emacs binaries will still use the removed API, they will also support > the removed API. You need just one linked DSOs which somehow manages to call a function in the glibc malloc implementation, and interesting things will happen. > What *could* be a problem is if the new glibc malloc API supplies > symbols that Emacs does not supply, and if other parts of the new glibc > use these symbols. But I don't see this happening either (and if it did > happen, poisoning __malloc_initialize_hook wouldn't fix it). We already have this problem with malloc_usable_size, and perhaps some of the aligned allocation functions. This reminds me of this glibc bug, which I've put on my list to fix: I think after that, at least glibc will be interposition-clean. > Perhaps poisoning __malloc_initialize_hook helps for some theoretical > applications, but for Emacs I don't see how it is a win. I'm worried that Emacs developers decide to ignore the API removal and keep using glibc malloc and the malloc_set_state function it provides. If we can turn the latter into a compatibility symbol during this development cycle, that would go a long way towards addressing my concern. Florian