From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10985 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: a bug in bindtextdomain() and strip '.UTF-8' Date: Sun, 29 Jan 2017 11:49:16 -0500 Message-ID: <20170129164916.GN1533@brightrain.aerifal.cx> 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: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1485708583 26551 195.159.176.226 (29 Jan 2017 16:49:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 29 Jan 2017 16:49:43 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11000-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 29 17:49:39 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 1cXsfO-0005W2-3T for gllmg-musl@m.gmane.org; Sun, 29 Jan 2017 17:49:26 +0100 Original-Received: (qmail 15828 invoked by uid 550); 29 Jan 2017 16:49:29 -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 15804 invoked from network); 29 Jan 2017 16:49:28 -0000 Content-Disposition: inline In-Reply-To: <20170129164008.GU17692@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10985 Archived-At: On Sun, Jan 29, 2017 at 05:40:08PM +0100, Szabolcs Nagy wrote: > * 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. So would this work? struct __generic_locale { int dummy; localt_t locale; }; Then allocate these objects with new. That way int* could point to the object (by pointing to its first member) and the locale_t could be obtained. Wasteful and ugly, but valid. Any other fix seems to assume int* can represent locale_t; I don't think that's valid for a "generic" implementation. Rich