Oleg Endo <oleg.e...@t-online.de> wrote: >> So apparently the strange behavior I observed is intended. Presumably >> there is some mechanism to ensure that these functions are always >> static-linked? But I don't see it. The libgcc spec I see is: >> >> *libgcc: >> %{static|static-libgcc:-lgcc >> -lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed >> -lgcc_s --no-as-needed}%{shared-libgcc:-lgcc_s%{!shared: -lgcc}}}} >> >> This explicitly omits -lgcc when -shared-libgcc is used with -shared. >> Thankfully __ashlsi3_r0 is not exported from libgcc.so.1 (as far as I >> can tell), so this will just be a link error rather than horribly >> wrong behavior, but it still seems like there's a bug here unless I'm >> misunderstanding something. I think the final %{!shared: -lgcc} in the >> spec is an error and should be replaced by simply -lgcc if there are >> targets where libgcc.a contains necessary symbols that are not/cannot >> be defined in libgcc_s.so.1. > > Hm, maybe, but I don't know enough about this, sorry. Kaz, maybe you > have a comment on that?
Sorry for my late reply. I was traveling. I think that almost linux targets uses linker script libgcc_s.so which includes -lgcc. See trunk/libgcc/config/t-slibgcc-libgcc. The target micro functions are statically linked with it. Regards, kaz