Re: A completely different approach to EH runtime

[Don Bashford <bashford at scripps dot edu>]

>>>>> "JB" == Joe Buck <jbuck@synopsys.COM> writes:

    JB> I'm perhaps less concerned about this issue than some others
    JB> because, as a C++ programmer, I'm used to the problem of
    JB> making sure that the correct version of libstdc++ is found.
    JB> To me, we already have a shared system library.  Still, people
    JB> are correct to raise it as an issue to make sure that we solve
    JB> it correctly, or tell people how to.

Ah.  In the /tsri/gnu setup I was describing there is a libstdc++.a
but no libstdc++.so* in the /tsri/gnu tree. I did nothing special to
make it so, so I guess that is the default up through gcc-2.95.x?
Will this change in gcc-3?

It sounds to me like the wrapper and/or NFS-trickery solutions you
describe can handle things, in principle, but with some inconvenience.
(And I lack the system privs./knowledge to do the NFS thing, I'll just
take your word for it.)  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?

As to the packaging thing, I see that you're right, libgcc can be its
own small package.  I now see where this was mentioned elswhere in the
thread.  On the other hand, this implies that if I give an executable
to someone outside TSRI, they'll also need a libgcc package, and for
that matter, perhaps a libstdc++ package.  I guess the problem goes
away if things are statically linked.

Just an ordinary C++ user, not a system hacker,
Don