rtld or lang/gcc cannot find libgcc_s.so.1
kabaev at gmail.com
Sat Feb 25 20:11:03 UTC 2012
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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 188 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120225/e041fb7d/signature.pgp
More information about the freebsd-ports