[Bug 227669] Review Request: ppl-0.9 - A modern C++ library providing numerical abstractions

[bugzilla at redhat.com]

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 at ioa.s.u-tokyo.ac.jp  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.