On Sat, May 9, 2015 at 7:31 AM, Szabolcs Nagy <n...@port70.net> wrote: > * H.J. Lu <hjl.to...@gmail.com> [2015-04-17 05:36:30 -0700]: >> On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek <ja...@redhat.com> wrote: >> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote: >> >> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in >> >> > creating yet another library for that. >> >> > So, IMHO beyond making the __cpu* entrypoints compat symbols only (@ >> >> > instead >> >> > of @@ symbol versions) the right fix is simply tweak init_gcc_spec, so >> >> > that >> >> > static_name is always linked in, in the switch combinations that it >> >> > isn't >> >> > right now of course after shared_name rather than before that. >> >> > I thought we've fixed that years ago... >> >> > > > I think the patch committed for this is suboptimal. > (it breaks with musl libc on x86 if libgcc_s is linked into a binary) > > the patch: > http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00878.html > original thread: > http://gcc.gnu.org/ml/gcc-patches/2015-03/msg01520.html > > The symbol versioning hack for __cpu_model and __cpu_indicator_init > makes them invisible to the musl dynamic linker so their relocation > fails with 'symbol not found' error. > (affects anything linked with -lgcc_s)
There are 4: 0000000000002b70 806 FUNC GLOBAL DEFAULT 12 __cpu_indicator_init@GCC_4.8.0 38: 00000000002153d0 16 OBJECT GLOBAL DEFAULT 25 __cpu_model@GCC_4.8.0 and 000000000215000 0000000400000001 R_X86_64_64 0000000000002b70 __cpu_indicator_init@GCC_4.8.0 + 0 0000000000215220 0000002600000006 R_X86_64_GLOB_DAT 00000000002153d0 __cpu_model@GCC_4.8.0 + 0 in libgcc_s.so.1. Musl ld.so must be fixed to handle it. -- H.J.