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 : > 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 >