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 mtasaka@xxxxxxxxxxxxxxxxxxx 2007-06-08 12:28 EST ------- (In reply to comment #22) > > * 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. > > * 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". As said above, normally non-devel package should not have dependency for -devel package without reasonable reason. > > > * 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. > > 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. > > * Definitions in header files > > - Some definitions in some header files are very dangerous > > and may easyly cause definition conflict. I will check the discussion above. > > * 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? > Anyway, the sources with which I am working are: I will appreciate it if you also upload the srpm, thanks! -- 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