Bug 434797

Summary: Review Request: ffcall-devel - foreign function call interface (needed for clisp)
Product: [Fedora] Fedora Reporter: Gérard Milmeister <gemi>
Component: Package ReviewAssignee: Gwyn Ciesla <gwync>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review, gwync, notting
Target Milestone: ---Flags: gwync: fedora-review+
kevin: fedora-cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-19 13:48:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Gérard Milmeister 2008-02-25 15:54:18 UTC
Spec URL:
http://math.ifi.uzh.ch/fedora/tmp/ffcall-devel.spec
SRPM URL: 
http://math.ifi.uzh.ch/fedora/tmp/ffcall-devel-1.10-1.fc7.src.rpm
Description:
This is a collection of four libraries which can be used to build
foreign function call interfaces in embedded interpreters.

(needed for recent versions of clisp)

Comment 1 Dan Horák 2008-02-25 16:13:45 UTC
I see a problem with packaging the static library. What is the reason not to
build dynamic libraries?

Comment 2 Gérard Milmeister 2008-02-25 16:31:41 UTC
By default static libraries are built. However I will ask, if shared libraries
are ok.

Comment 3 Bill Nottingham 2008-02-25 16:32:38 UTC
Any reason this is better or worse than libffi?

Comment 4 Gérard Milmeister 2008-02-25 16:39:03 UTC
ffcall has always been part of clisp. At the
request of Debian people, it has been extracted
as a separate library.

Comment 5 Gwyn Ciesla 2008-02-25 16:39:17 UTC
Shared libraries are greatly prefferred.

Comment 6 Gwyn Ciesla 2008-02-25 16:39:43 UTC
Pack

Comment 7 Gwyn Ciesla 2008-02-25 16:39:56 UTC
Ignore #6. :)

Comment 8 Gwyn Ciesla 2008-02-25 16:50:05 UTC
Package name is wrong, since this is a -devel only package, a la SDL, just call
it ffcall.

rpmlint has one error:
ffcall-devel-debuginfo.i386: E: empty-debuginfo-package
This debuginfo package contains no files.  This is often a sign of binaries
being unexpectedly stripped too early during the build, rpmbuild not being able
to strip the binaries, the package actually being a noarch one but erratically
packaged as arch dependent, or something else.  Verify what the case is, and
if there's no way to produce useful debuginfo out of it, disable creation of
the debuginfo package.

Combine all %docs on one line.

Add:

%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig

once you switch to shared libs.

I'm working on a mock build, but I'll want to do another after the change to
shared libs.

Otherwise, full review gives no other blockers than the above.

Comment 9 Gwyn Ciesla 2008-02-25 16:57:17 UTC
Mock build/BRs on static version are fine.

Comment 10 Gérard Milmeister 2008-02-25 17:40:17 UTC
http://math.ifi.uzh.ch/fedora/tmp/ffcall.spec
http://math.ifi.uzh.ch/fedora/tmp/ffcall-1.10-1.fc7.src.rpm

* Only two of the libraries are built shared
* debuginfo is still empty, I don't see any stripping and the
  -g flag is also present


Comment 11 Gwyn Ciesla 2008-02-25 18:10:40 UTC
ffcall.i386: W: unstripped-binary-or-object /usr/lib/libavcall.so.0.0.0
ffcall.i386: W: unstripped-binary-or-object /usr/lib/libcallback.so.0.0.0

Odd.  What's this about?

Comment 12 Mamoru TASAKA 2008-02-25 19:07:39 UTC
/usr/lib/rpm/find-debuginfo.sh tries to strip binaries
only with execution permission flags (0755, for example)

Comment 13 Gwyn Ciesla 2008-02-25 19:17:39 UTC
So this is acceptable, or should these be manually stripped?

Comment 14 Gwyn Ciesla 2008-02-25 19:22:51 UTC
Also, it would be fine to include the static libs also, in a -static package. 
SDL does this.

Comment 15 Kevin Kofler 2008-02-26 01:12:38 UTC
They should be "chmod +x"ed, that way the debuginfo creation will do the right 
thing.

Comment 16 Gérard Milmeister 2008-02-28 17:38:25 UTC
Bruno Haible the author of ffcall, prefers it not to be compiled shared.
His arguments are:
1) It is overkill: libavcall, libvacall, libcallback have less than 1 KB
of executable code (most of the real code is in the header files):
2) The main function here is compiled from non-PIC assembly language.
I.e. relocations would remain. The GNU linker supports shared libraries with
relocations on x86 systems. But only on x86!


Comment 17 Gwyn Ciesla 2008-02-28 18:08:18 UTC
Alright, in this case, go back to static, drop the shared, and we'll call it good.  

Will this build on ppc?

Comment 18 Gérard Milmeister 2008-02-29 17:13:47 UTC
(In reply to comment #17)
> Alright, in this case, go back to static, drop the shared, and we'll call it good.
What should be the name, ffcall, ffcall-devel, or ffcall-static?

> Will this build on ppc?
It should, since clisp previously built on ppc (but not ppc64).


Comment 19 Gwyn Ciesla 2008-02-29 17:23:21 UTC
1 package, called ffcall.

Comment 20 Gérard Milmeister 2008-02-29 18:25:59 UTC
http://math.ifi.uzh.ch/fedora/tmp/ffcall-1.10-1.fc7.src.rpm
http://math.ifi.uzh.ch/fedora/tmp/ffcall.spec

Disabled generating debuginfo

Comment 21 Gwyn Ciesla 2008-02-29 19:55:59 UTC
Ok, looks good. APPROVED.

Comment 22 Gérard Milmeister 2008-04-17 19:21:31 UTC
New Package CVS Request
=======================
Package Name: ffcall
Short Description: Libraries for foreign function call interfaces
Owners: gemi
Branches: F-8
InitialCC: gemi
Cvsextras Commits: yes

Comment 23 Kevin Fenzi 2008-04-18 02:08:54 UTC
cvs done.