On Fri, Aug 10, 2012 at 10:18:09PM +0400, Valeriy E. Ushakov wrote:
> Linking against libstdc++ wastes space and time at runtime.
On-demand paging will pull only the required parts in. As I said
earlier, the number of constructors is basically irrelevant to matter.
So yes, this just reduces the number of semi-statically linked programs.
> > and it leaks internals of how ${CXX} works unnecessarily
> > into the build. That's a good enough reason for me to keep it.
>
> The problem is that g++ links libstdc++ unconditionally. At the time
> the workaround you removed was added groff was the only c++ code in
> tree and we only used g++, so we added this kludge that does leak
> knowledge of libsupc++ into the build process. We now also have
> games/dab that is in c++ and doesn't need libstdc++ either.
There are a bunch of other things, including libGLU and ATF. Both use
real STL. Clang of course will in the future be a heavy user too.
There are some issues left due to the way our libraries are built, which
make it hard to completely remove the knowledge from anything outside
maybe share/mk for the purpose of dependency tracking. I'm working on
that part. I am still a bit unsure whether there will be a "low level"
C++ ABI in the midterm at all. There are simply not many good reasons
for having such an artifical library.
Joerg
