Re: libgcc

This is my conclusion about libgcc and softfloat so far:
a) Static vs. shared
* Static
* libgcc is usually statically linked.
* Shared
* libgcc_s is only for C++ exceptions.
* libgcc_s is linked by g++.
* No major problem seen in practice for now (there might be corner cases).
* No need to change this linkage condition / configuration.
* --eh-frame-hdr might be worth looking.
b) libgcc compatible functions in libc
* libc has libgcc compatible functions.
* Mainly softfloat and quad handling, but some others (e.g. sparc64's _Qp_*()
functions which libgcc doesn't have).
* Those compatible/conflicting functions were added for historical reasons.
(libgcc was immature.)
* Very few people are interested in looking at this. ;)
c) Migration
* Why
* Build all libgcc functions rather than hardcode the list.
* Mainly for MIPS64 softfloat.
* How
* Static libraries
* Move conflicting functions from libc to libgcc all together.
* Users should update them in sync.
* Otherwise you'll see conflicting symbol errors.
* Shared libraries
* Do these all together:
* Make conflicting functions as weak symbols, because these are only for
backward compatibility.
* Build complete set of functions in libgcc.
d) Architecture specifics
* arm
* Use gcc -msoft-float by default.
* Old dynamically linked binaries will use functions in libc.
* New ones will use libgcc.a.
* sh3
* Use gcc -msoft-float by default.
* Meant to not build softfloat functions in libgcc, but some were mistakenly
built.
* Pretty much same situation as ARM. Use libgcc functions from now.
* powerpc, m68k, sparc64
* Conditionally build libc softfloat (MKSOFTFLOAT).
* Should just work same as ARM's situation.
* mips, mips64
* Haven't had MKSOFTFLOAT.
* With new libgcc -msoft-float should just work nicely.
:
In short: I'll leave migrating functions in libc as weak symbols.
Masao
--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635