From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10988 Path: news.gmane.org!.POSTED!not-for-mail From: He X Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: a bug in bindtextdomain() and strip '.UTF-8' Date: Mon, 30 Jan 2017 09:32:30 +0800 Message-ID: References: <20170129133946.GT17692@port70.net> <20170129140747.GJ1533@brightrain.aerifal.cx> <20170129164008.GU17692@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f40304361e2c324d32054745cb40 X-Trace: blaine.gmane.org 1485739985 18022 195.159.176.226 (30 Jan 2017 01:33:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Jan 2017 01:33:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-11003-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 30 02:33:02 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cY0q5-0004Uf-1h for gllmg-musl@m.gmane.org; Mon, 30 Jan 2017 02:33:01 +0100 Original-Received: (qmail 13998 invoked by uid 550); 30 Jan 2017 01:33:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13968 invoked from network); 30 Jan 2017 01:33:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=XBweZYTS/WKdoGPzJ9F8unWzTm6eoc4k2SuCFYNqnyM=; b=Ko16EpAHWlNe73UCcyBAoIb5xnV7pBt5s+G9pyExMbwhSKC8LbntUgTlId5vCvVrsq 4KAGxMRtT+ZzD2N3N5+dFXpoUSkTZ+SpDrpXsYQRgnH4I8SMuQ7RwtkOzscDxj2GbTka JopQ7vhEePZciZypwRJjPR8AxIWi+ZSEYUPus2jcV6ZhT8gYUnck5YveRA8iiIssJkDj o1N0HVuQXQFNjmqVnSiWjbgPoVFIphh4voqHSl6SHN+ZgnH/eHnGgMHPYDADxja1rAiH 2W6ydSP0r0JHPZY8IBWV+LHSJW7qRlIbVxRPSP4/mCenLEE/9Epi6qF0sSSfnicvMRpj dJ3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=XBweZYTS/WKdoGPzJ9F8unWzTm6eoc4k2SuCFYNqnyM=; b=VFAV1dv5jFg5mt3jYVmAkWtZ9mazi3KOMX4x8oQ9ZBE/Gd/uO8KDSejYkxuoy35QhL rzCHP3EIedndqNlMrS66hX6SiC737VPSR5nZET2bc31HDmxsugbyE5kRX+LrERf2fJn3 XpXgyz2v2/7RgZP9roS75wlXLF+OoqFVnrlcrT+FSB8NPXAlCaXtfuxACZoO42wZb5cI 1hLvs5YE7dDlNVrmTXlnU2cEZ8+32noMQ7u/RcVNnlIOWhK+4JU5/jugMysqotHgpPEl 3J835kmjR5WUXYJneKNOMZ0SS8FIBWZfgj5JVR9B9VwBbnHenm6IlGLxjgHrtUKchdmO 67NA== X-Gm-Message-State: AIkVDXKageslom8Ir25kvBHPk6gE6uASjXGyycvUPbjz6FJKeBSWRxfSU3NtMPI8fwMvKzW7VxvtYvxIeyeqJQ== X-Received: by 10.176.23.22 with SMTP id j22mr9694913uaf.168.1485739970938; Sun, 29 Jan 2017 17:32:50 -0800 (PST) In-Reply-To: <20170129164008.GU17692@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:10988 Archived-At: --f40304361e2c324d32054745cb40 Content-Type: text/plain; charset=UTF-8 > To Szabolcs Nagy: that's not how abi works... 1. I know, what i meant, is that: these symbols seems only called by stdc++ themselves, i havnt seen any program invoke these symbols directly, they use std::locale() or something else. At least in my system, schroot does not need to recompile, neither chromium, they worked well just after i patched the toolchain. It's worth to checking if these symbols is used by other binaries out of stdc++, if just 1 or 2, or even no, it's not a big deal to apply this patch. But now i change my mind, as you said, this not a perfect solution, indeed there's a risk of breaking binaries. If it is on the way of upstreaming the patch, i wont do like this. > To Rich: So would this work?... 2. let me try it. :) 2017-01-30 0:40 GMT+08:00 Szabolcs Nagy : > * He X [2017-01-29 22:48:34 +0800]: > > 2. no other ways, musl will use generic config 100%, and then the > > exception, the run time error is hardcoded there; but i doubt if this > > really breaks binaries, the function is only called by libstdc++ itself. > > you cant only update the config, but does not update libstdc++. libstdc++ > > exported the same abi for common binaries, wont break most dynamic-loaded > > binary in my view. > > that's not how abi works.. you change the __c_locale typedef > of the generic config from int* to locale_t, such change > breaks abi and cannot be upstreamed to gcc. (it's unfortunate > that the c++ locale handling default for non-gnu systems > does not use posix locales correctly, but breaking abi > for all non-gnu systems is not an acceptable fix.) > > with your change the abi of libstdc++ would look like > the current gnu abi: > > $ grep __locale_struct libstdc++-v3/config/abi/post/ > x86_64-linux-gnu/baseline_symbols.txt |wc -l > 72 > > the abi on a musl based system is like > > $ nm -D /usr/lib/libstdc++.so.6 |grep __locale_struct |wc -l > 0 > > so with your patch if a compiled binary refers to any one > of those 72 symbols then the dynamic linker will fail to > load it on a musl based system. > --f40304361e2c324d32054745cb40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> To=C2=A0Szabolcs Nagy:=C2=A0that's not how abi works...
1. I know, what i meant, is that: t= hese symbols seems only called by stdc++ themselves, i havnt seen any progr= am invoke these symbols directly, they use std::locale() or something else.= At least in my system, schroot does not need to recompile, neither chromiu= m, they worked well just after i patched the toolchain. It's worth to c= hecking if these symbols is used by other binaries out of stdc++, if just 1= or 2, or even no, it's not a big deal to apply this patch.
<= br>
But now i change my mind, as you said, this not a perfect sol= ution, indeed there's a risk of breaking binaries. If it is on the way = of upstreaming the patch, i wont do like this.

> = To Rich:=C2=A0So would this work?...<= /div>
2. let me try it. :)
=
2017-01-30 0:40 GMT+08:00 Szabolcs Nagy <nsz@p= ort70.net>:
* He X <xw897002528@gmail.com> [2017-01= -29 22:48:34 +0800]:
> 2. no other ways, musl will use generic config 100%, = and then the
> exception, the run time error is hardcoded there; but i doubt if this<= br> > really breaks binaries, the function is only called by libstdc++ itsel= f.
> you cant only update the config, but does not update libstdc++. libstd= c++
> exported the same abi for common binaries, wont break most dynamic-loa= ded
> binary in my view.

that's not how abi works.. you change the __c_locale typedef
of the generic config from int* to locale_t, such change
breaks abi and cannot be upstreamed to gcc. (it's unfortunate
that the c++ locale handling default for non-gnu systems
does not use posix locales correctly, but breaking abi
for all non-gnu systems is not an acceptable fix.)

with your change the abi of libstdc++ would look like
the current gnu abi:

$ grep __locale_struct libstdc++-v3/config/abi/post/x86_64-linux-gnu/b= aseline_symbols.txt |wc -l
72

the abi on a musl based system is like

$ nm -D /usr/lib/libstdc++.so.6 |grep __locale_struct |wc -l
0

so with your patch if a compiled binary refers to any one
of those 72 symbols then the dynamic linker will fail to
load it on a musl based system.

--f40304361e2c324d32054745cb40--