This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A completely different approach to EH runtime
- To: gcc at gcc dot gnu dot org
- Subject: Re: A completely different approach to EH runtime
- From: thospel at mail dot dma dot be (Ton Hospel)
- Date: Wed, 28 Feb 2001 23:21:06 +0000 (UTC)
- Organization: lunix confusion services
- References: <200102281702.RAA04980@cam-mail2.cambridge.arm.com>
- Reply-To: thospel at mail dot dma dot be (Ton Hospel)
- Xref: Home.Lunix mail.ecgs:44487
In article <200102281702.RAA04980@cam-mail2.cambridge.arm.com>,
Richard Earnshaw <rearnsha@arm.com> writes:
>> Is this incredibly naive ?
>>
>
> Yes, (one I fell for once).
>
>> As soon as you add functions, give libgcc_s.so a new major number, but
>> only put the NEW functions in there.
>> Have the old functions however come from the OLD library (have a
>> unique symbol in each of them so you can pull it in)
>
> If you bump the major verison of libgcc_s.so, you have to bump the major
> version of libc.so and hence every other shared library in the system.
>
I still seem to be missing the point. Why ?
I presume you are talking about when you compile libc with the new
compiler, presumably using the new functions and therefore referring to
the new libgcc_s.so. What would go wrong if I
did not bump the libc major ? It would be pulling in the new functions
with the new libgcc_s.so and the old functions from the old libgcc_s.so,
which would get shared with the old libgcc_s.so refered to by an old
program even if it loads the new libc, so everything would still be
unique, no ?