Re: A completely different approach to EH runtime

[Joe Buck <jbuck at synopsys dot COM>]

> 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?

With current gcc releases you must enter the --enable-shared flag to
get a shared libstdc++.so.  With current snapshots, it is the default.

> 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?

Static linking is one way to avoid such problems, yes.

The NFS trickery isn't really so tricky.  The idea is that we create
two different versions of /opt/gcc-3.1/lib, one with the lib and one
without, and then mount the appropriate one on each host.

> 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.