This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
- To: drepper at cygnus dot com (Ulrich Drepper)
- Subject: Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 10 Jul 2000 21:34:49 -0600
- cc: Mark Kettenis <kettenis at wins dot uva dot nl>, hjl at valinux dot com, rth at twiddle dot net, libc-hacker at sourceware dot cygnus dot com, gcc at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <m3k8etle7z.fsf@otr.mynet.cygnus.com>you write:
> Mark Kettenis <kettenis@wins.uva.nl> writes:
>
> > This isn't necessary at all. The shared libgcc belongs in /lib. If
> > the GCC folks do their job properly, and take care of backwards
> > compatibility issues, installing GCC can simply upgrade it if the
> > version provided with the new GCC has the highest "version number".
>
> 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.
What would you recommend then? Considering that we can not tie GCC to glibc
since GCC is used on a lot of systems that do not use glibc?
We're certainly open to suggestions -- a shared libgcc has a number of nasty
problems that need solving (but it also solves a huge number of nasty problems
that we've had over the years).
jeff