Bug 434797 - Review Request: ffcall-devel - foreign function call interface (needed for clisp)
Review Request: ffcall-devel - foreign function call interface (needed for cl...
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gwyn Ciesla
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-02-25 10:54 EST by Gérard Milmeister
Modified: 2008-04-19 09:48 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-19 09:48:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
limburgher: fedora‑review+
kevin: fedora‑cvs+

Attachments (Terms of Use)

  None (edit)
Description Gérard Milmeister 2008-02-25 10:54:18 EST
Spec URL:
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 11:13:45 EST
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 11:31:41 EST
By default static libraries are built. However I will ask, if shared libraries
are ok.
Comment 3 Bill Nottingham 2008-02-25 11:32:38 EST
Any reason this is better or worse than libffi?
Comment 4 Gérard Milmeister 2008-02-25 11:39:03 EST
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 11:39:17 EST
Shared libraries are greatly prefferred.
Comment 6 Gwyn Ciesla 2008-02-25 11:39:43 EST
Comment 7 Gwyn Ciesla 2008-02-25 11:39:56 EST
Ignore #6. :)
Comment 8 Gwyn Ciesla 2008-02-25 11:50:05 EST
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.


%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 11:57:17 EST
Mock build/BRs on static version are fine.
Comment 10 Gérard Milmeister 2008-02-25 12:40:17 EST

* 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 13:10:40 EST
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 14:07:39 EST
/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 14:17:39 EST
So this is acceptable, or should these be manually stripped?
Comment 14 Gwyn Ciesla 2008-02-25 14:22:51 EST
Also, it would be fine to include the static libs also, in a -static package. 
SDL does this.
Comment 15 Kevin Kofler 2008-02-25 20:12:38 EST
They should be "chmod +x"ed, that way the debuginfo creation will do the right 
Comment 16 Gérard Milmeister 2008-02-28 12:38:25 EST
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 13:08:18 EST
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 12:13:47 EST
(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 12:23:21 EST
1 package, called ffcall.
Comment 20 Gérard Milmeister 2008-02-29 13:25:59 EST

Disabled generating debuginfo
Comment 21 Gwyn Ciesla 2008-02-29 14:55:59 EST
Ok, looks good. APPROVED.
Comment 22 Gérard Milmeister 2008-04-17 15:21:31 EDT
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-17 22:08:54 EDT
cvs done.

Note You need to log in before you can comment on or make changes to this bug.