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

[Martin v. Loewis]

> Doing things outside gcc has the advantage of not delaying the
> release.  The worst case is that the new release cannot be used on a
> certain platform but that's it.  And this would be the fault of the
> people writing the libgcc.so for that arch/OS.

Maybe I'm missing another point here. I'm sure we can all argue
endlessly on that. However, this is GNU source, so you can take out
whatever you want from gcc and bundle it in whatever way you please.

You can then submit patches to gcc saying that certain things won't be
needed if some autoconf test determines they are already there. If you
think you (as the glibc group, or as the Ulrich Drepper individual)
can maintain this over the years to come - why don't you just go
ahead and do it?

> Besides, I have not heard a single convincing argument why libgcc.so
> should be generate as part of gcc.  What do you want to achieve?

It is likely that gcc maintainers will add functions to libgcc as they
please, and that the code generated by gcc will rely on these
functions being inside libgcc. So how should gcc proceed on a system
where these new functions are not present in the system libgcc?

Regards,
Martin