On 11/05/15 14:05, Jakub Jelinek wrote: > On Mon, May 11, 2015 at 01:39:17PM +0100, Szabolcs Nagy wrote: >> fyi, musl loader loads libstdc++ just fine because it has no > > But will it load any shared library that uses any of the 26 (if I count well > on x86_64) @ symbols from libstdc++.so.6?
i looked, but all of those symbols have @@ variant too so at least the libraries would load with musl. >> musl may end up supporting @version but that's an independent >> quest. > > It is not independent. If musl claims to support symbol versioning, it > should support it properly, if not, then supposedly gcc configured for musl > can't be compatible with gcc configured for other linux C libraries, and > should force symbol versioning off. ok, but the current solution does not make that easy: configuring gcc with --disable-gnu-indirect-function --disable-symvers has no effect on libgcc_s.so.1 on linux. (i can try to create a patch that removes the new -DUSE_ELF_SYMVER from the libgcc cflags for musl, but that seems a worse solution than the weak alias one). (note that previously a simple spec file was enough to use an existing gcc on linux to build things against musl... this didnt work for c++ code that used libstdc++ headers, but now it also fails for any build using -lgcc_s).
