Bug 13807

I'm sorry for doing so, but I will reopen this bug.
WONTFIX is a good bug resolution, but there is just one
trivial question: WHY !?  At least one single comment please...

I don't have the above compiler/glibc packages to test this with. It doesn't
happen
with the versions in rawhide that we use to compile this package.
I don't want to add an additional dependency to the math lib if not
necessary.

Can you check if 1.16.1 still has this bug once it is uploaded into rawhide?

I don't see groff-1.16.1 yet, only -1.16-6 dated Jul 20 02:54.
Maybe I need to wait (I use ftp.sunet.se; connection directly to
redhat is extremly slow) while mirrors gets updated.

BTW, I always use "current" compiler/binutils/glibc (namely,
currently I use:
  glibc-2.1.91-18
  gcc-2.96-46
  binutils-2.10.0.18-1
that is from beta pinstripe, or from 20-jul rawhide).  And that current
packages also won't compile groff, for the same reason.  I don't know
why it can be compiled at your environment.  Other tools/etc of interest:
kernel + kernel-headers kernel-2.2.16-17 (tweaked a bit, but does not matter),
glibc-devel the same as glibc.

But I know now why this bug was opened -- i.e. what's the cause.

But some words before.  As you noted, you won't add unneded .so's
for particular executable that don't used anyway. Grn maybe does not need
libm; but other programs from the same package needs.  And this is interesting.
Sometime ago I looked to dependances of executables in many packages, and found
that this is a common practice to just use "LIBS" for _all_ programs in
package, without attention to each one.  Say, (hypotetically) "printf" need
to be linked with -lm, but "sort" from the same package does not.  But linked
with -lm anyway.  Smbd depends on libcurses and libreadline (this was fixed)!.
And so on.  So, here is a question:  should each executable be linked _only_
with libraries it really need?  Note that for portability reasons this is very
hardly sometimes...  But anyway, I think that yes, unneded libraries should
be thrown away, and as I can see, you agree with this.

Now the cause itself.  I noted that groff don't use any of libstdc++
features.  And so, I build it with command like:
 $ CXX=gcc rpm --rebuild groff-xxx.src.rpm
(note CXX=).  And _in_this_case_ it needs -lm for grn!.
I just tested -- without this "CXX=" it compiles fine, and _all_ executables
depends on libstdc++-something.  Two of my servers does ever have libstdc++
installed (but have groff (for man) and some other packages that normally
depend on libstdc++).   This is the same issue as for -lm for particular
executable inside package :)

Ok, I know also why this compiles fine with g++: libstdc++ itself depends
on -lm, so linker automatically adds -lm when compiling with -lstdc++.
So, -lm _does_not_needed_at_all for groff! :)

Grn really depends on -lm, and this is a bug in groff package:
 $ pwd
 /home/mjt/rpm/build/groff-1.16/src/preproc/grn
 $ fgrep pow *.cc
 hgraph.cc:         pow((double) h[i - 1], (double) 2.0) / a[i - 1];
 hgraph.cc:          pow((double) h[i + 1], (double) 2.0) / a[i - 1];
 $ _
Here, in hgraph.cc, there are calls to pow() routine that is on -lm.

BTW, what do you think about usage of libstdc++ in program(s) such a
groff, and how [cg]++ can eliminate dependance on it if it does not really
used (if should)?

BTW2, what is "VERIFIED" resolution mean?  Is it "RESOLVED"?