Bug 13807 - groff-1.16-3 won't compile
Summary: groff-1.16-3 won't compile
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: groff   
(Show other bugs)
Version: 1.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Florian La Roche
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-07-12 16:54 UTC by Michael Tokarev
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-07-14 11:23:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michael Tokarev 2000-07-12 16:54:31 UTC

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

Comment 1 Michael Tokarev 2000-07-14 11:22:58 UTC
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...

Comment 2 Florian La Roche 2000-08-07 13:58:16 UTC
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?

Comment 3 Michael Tokarev 2000-08-07 14:33:26 UTC
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:
 $ pwd
 $ 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"?

Note You need to log in before you can comment on or make changes to this bug.