mailing list of musl libc
 help / color / mirror / code / Atom feed
From: He X <xw897002528@gmail.com>
To: musl@lists.openwall.com
Subject: Re: Re: a bug in bindtextdomain() and strip '.UTF-8'
Date: Mon, 30 Jan 2017 20:36:41 +0800	[thread overview]
Message-ID: <CAPG2z09PTwxHrSo95ter_BOBn-2hLpCSvheRSqOzV7ZBed4aoA@mail.gmail.com> (raw)
In-Reply-To: <20170129164916.GN1533@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]

worked!  http://paste.ubuntu.com/23893379/
-su-4.4# nm -D /usr/lib/libstdc++.so.6 |grep __locale_struct |wc -l
0
anything i missed? it it acceptable ? and how could i post this to the
upstream?

2017-01-30 0:49 GMT+08:00 Rich Felker <dalias@libc.org>:

> On Sun, Jan 29, 2017 at 05:40:08PM +0100, Szabolcs Nagy wrote:
> > * 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
> > > 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
>

[-- Attachment #2: Type: text/html, Size: 2894 bytes --]

  reply	other threads:[~2017-01-30 12:36 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-20 11:25 He X
2017-01-29  4:52 ` He X
2017-01-29 13:39   ` Szabolcs Nagy
2017-01-29 14:07     ` Rich Felker
2017-01-29 14:48       ` He X
2017-01-29 15:55         ` Rich Felker
2017-01-29 16:14           ` He X
2017-01-29 16:33             ` Rich Felker
2017-02-08 10:13               ` He X
2017-02-08 14:31                 ` Rich Felker
2017-02-09  9:49                   ` He X
2017-02-11  2:36                     ` Rich Felker
2017-02-11  6:00                       ` He X
2017-02-11 23:59                         ` Rich Felker
2017-02-12  2:34                         ` Rich Felker
2017-02-12  6:56                           ` He X
2017-02-12  7:11                             ` He X
2017-02-13 17:08                             ` Rich Felker
2017-02-13  8:01                           ` He X
2017-02-13 13:28                             ` Rich Felker
2017-02-13 14:06                               ` He X
2017-02-13 17:12                                 ` Rich Felker
2017-03-04  8:02                                   ` He X
2017-03-17 19:27                                     ` Rich Felker
2017-03-17 19:37                                       ` Rich Felker
2017-03-18  7:34                                         ` He X
2017-03-18 12:28                                           ` Rich Felker
2017-03-18 13:50                                             ` He X
2017-02-13 14:12                               ` He X
2017-02-13 17:13                                 ` Rich Felker
2017-01-29 16:37         ` Rich Felker
2017-01-30  0:37           ` He X
2017-01-30 14:17           ` He X
2017-01-29 16:40         ` Szabolcs Nagy
2017-01-29 16:49           ` Rich Felker
2017-01-30 12:36             ` He X [this message]
2017-01-30 13:05               ` Szabolcs Nagy
2017-01-30  1:32           ` He X

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPG2z09PTwxHrSo95ter_BOBn-2hLpCSvheRSqOzV7ZBed4aoA@mail.gmail.com \
    --to=xw897002528@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).