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)
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 are ok.
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.
Pack
Ignore #6. :)
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.
Mock build/BRs on static version are fine.
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
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 thing.
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.
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
Ok, looks good. APPROVED.
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
cvs done.