Re: <iostream> now part of the libstdc++ binary

[Joe Buck <Joe dot Buck at synopsys dot COM>]

I wrote:
> iostream-inst.cc will produce a module iostream-inst.o in the library,
> but it looks to me that this unit will only be included in a statically
> linked executable if some symbol in basic_iostream<char> or
> basic_iostream<wchar_t> is referred to.

> So I guess you're talking about dynamically linked executables?  Will
> minimalists who want to avoid streams even link against libstdc++.so?

On Fri, Nov 17, 2006 at 01:02:47PM -0500, Howard Hinnant wrote:
> Actually I was concerned about both static and dynamic clients.  My  
> understanding was that dead-stripping static initialization lists  
> could cause conforming C++ code to break (unless the linker could  
> prove the static code had no side effects).

Right, you can't strip static initializers with side effects.  But
for statically linked executables, you only get the stream-setup hook
if the corresponding .o file is pulled in, which will only happen if
one of the symbols defined by the explicit initiation is referred to.
So there will be no initializer to strip.  I've had to deal with this
all the time in C++ code that used the object-factory pattern or whatever
it is officially called; you have to consider which code from a library
will be pulled in by the linker or you don't get constructor side effects
you may want.

For a program that uses libstdc++.so, all of the initializers must be
called, so all programs linked against the so will get streams set up.