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