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: bashford at scripps dot edu
- Subject: Re: A completely different approach to EH runtime
- From: jlarmour at redhat dot com (Jonathan Larmour)
- Date: Fri, 23 Feb 2001 14:19:49 GMT
- Cc: gcc at gcc dot gnu dot org, Joe Buck <jbuck at synopsys dot COM>
- Newsgroups: cygnus.egcs
- Organization: Red Hat UK Ltd.
In article <200102230117.RAA21959@gage.scripps.edu> you write:
>But maybe in an environment like ours it's
>easier just to go on making both libstdc++ and libg++ static. Is
>there any reason NOT to make them static besides larger executables?
I assume you mean libgcc, not libg++.
The answer is yes, because then the unwind information will not be
shared between the program and all the DSOs it uses.
One aspect that has been brought up before but not emphasised is that
because of this it becomes vital that libgcc always has the same
soname *forever*. Otherwise inevitably at some point a program will use
different DSOs that want different libgcc versions, which means
the unwind information is now duplicated. This could well be fatal.
I know from bitter experience with libstdc++ that having different
DSOs requiring different sonames for libstdc++ is a recipe for disaster
and segfaults.
We could commit to using version scripts, but those are only supported
by GNU dynamic linkers IIRC.
And if we commit to relying on GNU ld.so's, then we may as well do
what rth suggested and solve this problem by extending it.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine