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@xxxxxxxxxxx 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review