This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A completely different approach to EH runtime


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]