Red Hat Bugzilla – Bug 434797
Review Request: ffcall-devel - foreign function call interface (needed for clisp)
Last modified: 2008-04-19 09:48:14 EDT
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)
I see a problem with packaging the static library. What is the reason not to
build dynamic libraries?
By default static libraries are built. However I will ask, if shared libraries
Any reason this is better or worse than libffi?
ffcall has always been part of clisp. At the
request of Debian people, it has been extracted
as a separate library.
Shared libraries are greatly prefferred.
Ignore #6. :)
Package name is wrong, since this is a -devel only package, a la SDL, just call
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
Otherwise, full review gives no other blockers than the above.
Mock build/BRs on static version are fine.
* 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
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?
/usr/lib/rpm/find-debuginfo.sh tries to strip binaries
only with execution permission flags (0755, for example)
So this is acceptable, or should these be manually stripped?
Also, it would be fine to include the static libs also, in a -static package.
SDL does this.
They should be "chmod +x"ed, that way the debuginfo creation will do the right
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!
Alright, in this case, go back to static, drop the shared, and we'll call it good.
Will this build on ppc?
(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).
1 package, called ffcall.
Disabled generating debuginfo
Ok, looks good. APPROVED.
New Package CVS Request
Package Name: ffcall
Short Description: Libraries for foreign function call interfaces
Cvsextras Commits: yes