Red Hat Bugzilla – Bug 13807
groff-1.16-3 won't compile
Last modified: 2008-05-01 11:37:56 EDT
preproc/grn required some routines from math library,
while "MLIB=$(LIBM)" line is missing from
src/preproc/grn/Makefile.sub. I don't know if this is an
"application's aothor"'s error or gcc/glibc error
(like missing memcpy from kernel compilation by gcc-2.96.x)
Simple adding this line to this file will throw problem
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
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
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:
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:
$ 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"?