Re: Shared library annoyance with gcc-3_0-branch

[Linus Torvalds <torvalds at transmeta dot com>]

In article <009F806F.8CD52B60.4@baby.bedroom.gen.nz>,
Clive Nicolson  <srwmcln@baby.bedroom.gen.nz> wrote:
>
>Linux and other OS's (or runtime systems) need either to provide EH
>support as part of the "system" (VMS does this, as do other well
>designed systems).

This is not necessarily a bad idea to strive for.  But in practice it
tends to be scuttled by the need to support older versions, and support
OS's that you can't easily change. 

>My feeling is that it would be better if the linux gurus provided a backward
>and forward compatible unique name/value system rather than a builtin EH system.

You can easily do it in user space with a number of approaches. One is
to reserved a specific area of virtual memory, and use that as a global
pointer. The problem is the "backwards compatibility", and the fact that
glibc people seem to have a hard time communicating.

Both of these are easy to solve if you just bite the bullet and make
glibc jump to the next major number together with gcc-3.0 and say that
gcc exception handling doesn't work with glibc-6, and vice versa.

But for some reason I've never understood, glibc people don't seem to
like changing the version number.  In fact, last I looked, HJL created
an incompatible library and called it the same old version on purpose. 
So this solution doesn't seem to be a valid solution, even if it's easy. 

(Personally, I think that glibc should be _forced_ to change it's
version number every time it comes up with a new release, and only use
the minor numbers for the _really_ small changes that do not change any
behaviour or add any new functionality.  I'd rather have five copies of
the libraries than have one library that doesn't really work with all
binaries). 

Basically, I'm saying that the whole "Linux" issue doesn't exist. It's a
"glibc" issue, and even there it seems to be more about people than
about technology. Which is so often the case.

                Linus