Re: CVS commit: src/gnu/usr.bin/groff

["Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>]

On Fri, Aug 10, 2012 at 19:10:37 +0200, Joerg Sonnenberger wrote:

> On Fri, Aug 10, 2012 at 08:32:16PM +0400, Valeriy E. Ushakov wrote:
> > On Fri, Aug 10, 2012 at 17:04:09 +0200, Joerg Sonnenberger wrote:
> > 
> > > On Fri, Aug 10, 2012 at 06:15:43PM +0400, Valeriy E. Ushakov wrote:
> > > > On Fri, Aug 10, 2012 at 12:12:22 +0000, Joerg Sonnenberger wrote:
> > > > 
> > > > > Module Name:  src
> > > > > Committed By: joerg
> > > > > Date:         Fri Aug 10 12:12:22 UTC 2012
> > > > > 
> > > > > Modified Files:
> > > > >       src/gnu/usr.bin/groff: Makefile.inc
> > > > [...]
> > > > > 
> > > > > Log Message:
> > > > > Don't link explicitly against libsupc++, just use the normal C++
> > > > > linkage.
> > > > 
> > > > Why?
> > > 
> > > When using static linkage, it doesn't make a difference. When using
> > > dynamic linkage, it stops the redundant copies. libstdc++ is not that
> > > heavy loaded with constructors to provide a significant overhead.
> > 
> > By the same line of reasoning, libsupc++ is so tiny that redundant
> > copies (a page or two of text) are not that much to provide
> > significant overhead, certainly less overhead than libstdc++.so.
> 
> It wastes space

Linking against libstdc++ wastes space and time at runtime.


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

I guess you are working on clang support, so leaking libsupc++ into
the build gets in your way.  Please, instead of always linking
libstdc++ make it possible for a c++ program to express "i don't need
libstdc++" in a clean way.

-uwe