With: gcc-2.95.3-0.20000517 glibc-2.1.90-17 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 away.
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"?