Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Richard Earnshaw <rearnsha at arm dot com>]

> On Fri, Jul 14, 2000 at 05:46:22PM +0100, Richard Earnshaw wrote:
> 
>  > Yes.  They are still there.  And because of the way shared libs work I 
>  > believe they have to be.  Consider something like __divsi3 and then assume 
>  > that it isn't in libc.so and that we don't have a shared libgcc.  There 
>  > are two ways the linker could work:
>  > 
>  > 1) The linker doesn't resolve symbols from shared libs into archives: If 
>  > it is needed by libc.so and it weren't needed by the application the 
>  > linker wouldn't put it into the application.  So we would get a run-time 
>  > fault when the symbol isn't found.
>  > 
>  > 2) The linker does resolve symbols from shared libs into archives: this 
>  > would result in every symbol possibly needed by libc from libgcc getting 
>  > put into the static part of the application even if it weren't needed for 
>  > that application (the linker can't pick apart the dependencies of the 
>  > shared lib).  This leads to code bloat since now we include __divsi3 in 
>  > our app even if we never call it.
> 
> Err... ok, now I think I'm confused.
> 
> Looking at NetBSD shared library build rules, we basically see what
> amounts to:
> 
> 	ld -x -shared -soname libc.so.12 -o libc.so.12.62 \
> 	    /usr/lib/crtbeginS.o \
> 	    --whole-archive libc_pic.a --no-while-archive \
> 	    /usr/lib/crtendS.o
> 
> Hm, are you referring to just the quad support library?  Otherwise,
> what kinds of compiler support routines would libgcc be providing on
> e.g. the Alpha?
> 

Yes, these are really functions that should be part of libgcc. I suspect 
there is very little else needed on the Alpha, but consider the ARM.  For 
that you also need all the soft-float functions and __divsi3.  Currently 
we build these directly into libc.so so it looks like we have no 
dependency.  But if a new version of gcc were to introduce a new low-level 
function we would have to rebuild our libc.so to supply it, since 
otherwise any other shared library built with that new version of gcc 
might require that interface.

This is precisely the same argument as is being covered with glibc, except 
that we seem to have done what they are proposing already.  All the 
reasons that have been presented that it shouldn't be done there apply to 
NetBSD as well.

R.