Re: new syscall stub support for ia64 libc

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Dec 08, 2003 at 02:17:39PM -0800, David Mosberger wrote:
>   Jakub> I've briefly looked at .unwabi and will fix it in
>   Jakub> unwind-ia64.c as well as other issues which I'll come over.
> 
> If you really want to keep the old unwinder alive, could you at least
> put it in a separate (shared) library called libunwind.so?  I'm
> concerned about version-mismatches that can occur when libgcc_eh.a
> gets linked into a program and then libgcc_s.so gets loaded as well.
> The version conflict arises because of potential differences in the
> _Unwind_Context structure.  If libgcc_eh.a doesn't implement any part
> of the _Unwind_*() routines, such version conflicts should be much
> less likely.  This is the approach I'm now pursuing with libunwind: it
> implements all the _Unwind_*() routines needed by GCC so no part of
> that interface gets implemented in libgcc_eh.a anymore.  libunwind has
> been updated already, but I haven't submitted a GCC patch yet, because
> I can't get through to the CVS server (due to the savannah break-in, I
> assume).

Why a separate shared library and not libgcc_s.so?
The code certainly needs to be in libgcc_eh.a too for statically linked
apps.  Similarly C++ apps and C apps linked with -shared-libgcc.
The only problematic case in this regard is C app using -fexceptions
linked without -shared-libgcc, right?

Now, the thing is, no matter what shared library you want, for that case
solving it is quite hard.  Implying -shared-libgcc for all programs
is an unnecessary bloat for the 99% of C apps which don't need it.
But libgcc_eh.a used for non-static links cannot easily use dlopen either
- that would bloat all apps with -ldl.

	Jakub