Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: ppl-0.9 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-06-08 12:52 EST -------
rpmlint The result of rpmlint for srpm, binary rpms and the installed rpms is attached.
SUMMARY:
- Undefined non-weak symbols
- Two libraries have undefined non-weak symbols.
This means:
-bash-3.2# ldd -r /usr/lib/libppl.so | sort undefined symbol: __gmpz_cmp (/usr/lib/libppl.so) undefined symbol: __gmpz_mul (/usr/lib/libppl.so) undefined symbol: __gmpn_popcount (/usr/lib/libppl.so) undefined symbol: __gmpq_equal (/usr/lib/libppl.so)
<snip> ----------------------------------------------------------- For example, /usr/lib/libppl.so contains undefined non-weak symbols. For this library, perhaps linkage against /usr/lib/libgmp??.so is missing.
Thanks for the tip. I will investigate this immediately.
- devel packge dependency on non-devel package
- Please explain
- why ppl-swiprolog requires ncurses-devel
Sorry, I do not understand this question.
%package swiprolog Summary: The SWI-Prolog interface of the Parma Polyhedra Library Group: Development/Libraries BuildRequires: pl >= 5.6.0, readline-devel Requires: ppl = %{version}-%{release}, ppl-pwl = %{version}-%{release}, pl >= 5.6.0, readline-devel
So ppl-swiprolog has readline-devel for "Requires".
I see. The problem was that above you wrote "ncurses-devel".
As said above, normally non-devel package should not have dependency for -devel package without reasonable reason.
You asked me to add this as a workaround. As a reminder, `pl' should require `readline-devel', but it doesn't. You asked me to file a bug for `pl' (which I did) and to work around that problem (which I did by requiring `readline-devel' myself). Perhaps I misunderstood you.
* why ppl-utils requires glpk-devel
Because one of the utilities requires the GLPK library and, as far as I know, there is only one package providing it, which is glpk-devel
No. GLPK *library* is provided by glpk rpm and if you worry about library dependencies, then they are checked by rpmbuild automatically and so the explicit Requires for glpk-devel should be removed.
I am probably misunderstanding again. Here I see only the packages
glpk-devel-4.13-1.fc6 glpk-utils-4.13-1.fc6
Where do you get the `glpk' package from?
Usually non-devel packages should not require devel related packages.
I see. What should I do then?
If you have reasonable reasons, it can be ignored as exceptions.
My only reason is that I thought the `glpk' package did not exist.
- About libppl_gprolog.so:
This one. I thought I had fixed it by adding an -rpath option, ppl_gprolog works, but now I get the following:
- /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
ERROR 0001: file '/usr/lib64/ppl/libppl_swiprolog.so' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR 0001: file '/usr/lib64/ppl/ppl_yap.so' contains a standard rpath '/usr/lib64' in [/usr/lib64]
<snip> > Net result: I am totally confused. Your newest spec file uses --disable-rpath + adds ppl-0.9-makefiles.patch to add rpath on ppl_gprolog. Do you see this rpath problem on the newest spec file?
Yes.
Anyway, the sources with which I am working are:
I will appreciate it if you also upload the srpm, thanks!
Because of the error above, the srpm is not generated.