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

[Joern Rennecke <amylaar at cygnus dot co dot uk>]

> Letting it all to the gcc folks has one major drawback: they will
> either have to keep track of ABI changes for every single
> architecture/OS combination or they will have to bump the version
> number whenever something changed on any of the supported platforms.
> The latter has the concequences that after a while you'l have dozends
> of libgcc.so of which you cannot remove a single one unless you are
> making sure everything is recompiled.  This latter approach will never
> get my blessing but of course I cannot prevent the gcc people from
> making this mistake.

I suppose we could have a target macro for the libgcc.so version number
that gets bumped up whenever the ABI changes.
Simultanously, there'd be a version number for libgcc2.c to keep
track of new and changed functions.  The build mechanism will then
select the higher number for libgcc.so

Whoever the version number is bumped up for a target you have to use
a number that is lager than the current libgcc2 number, and you have to
update a comment next to the libgcc version number what the next number
should be, unless there is already a larger number there.

Or we could be lazy and use a major / minor number scheme for abi / libgcc2.