Re: rtld or lang/gcc cannot find libgcc_s.so.1

On Sat, 25 Feb 2012 10:41:59 -0800
Tim Kientzle <tim_at_kientzle.com> wrote:

> 
> On Feb 23, 2012, at 9:16 AM, Alexander Kabaev wrote:
> 
> > On Tue, 21 Feb 2012 21:11:13 -0800
> > Tim Kientzle <tim_at_kientzle.com> wrote:
> > 
> >> 
> >> If I understand correctly, the libgcc in base is pretty stripped
> >> down compared to "regular" libgcc, because most of that
> >> stuff is in our libc instead. 
> >> 
> > 
> > You understand it a bit wrong, but your conclusions are correct.
> > libgcc in base is not stripped in any way and is supposed to be
> > identical to one coming from upstream.
> 
> So where is __umodsi3 supposed to be defined for ARM?
> 
> In FreeBSD, libgcc refers to it but does not define it.
> It's defined in libc.
> 
> I stumbled across this trying to link some freestanding
> ARM code using the native cross-compilers.  The link
> failed if I used -nostdlib because of a handful of symbols
> such as this.
> 
> Tim

I do not know how embedded architectures split it these days and I am
not even sure if we have an official ARM port in FSF GCC, but in
general these belong in static portion of libgcc.a. If you'd look at
bmake glue in gnu/lib/libgcc, you will see that building of __umodsi was
there but was disabled by our arm folks presumably because of switch to
our own complete softfloat implementation that happens to be in libc.
They probably should not have disabled integer math stuff along with
libgcc's incomplete floating point implementation, but I guess they
had their reasons. Non-embedded architectures do not do that and for
amd64/i386 each GCC import since 3.<something> ensured that libgcc_s.so
matched one produced by upstream symbol-by-symbol.

-- 
Alexander Kabaev