libffcall should now be based on the cvs head, not 1.10 tar ball

[sds]

Binary package hint: libffcall1

package libffcall is based on the 1.10 tar ball from santafe.
this is obsolete as per http://www.gnu.org/software/libffcall/
you should get the sources from the cvs as described in
https://savannah.gnu.org/projects/libffcall
many patches, including the debian/ubuntu ones,
have been incorporated into the cvs,
and no risky new features are being introduced,
so it is safe to rely on the cvs.

[sds (sds-gnu)]

when clisp is linked against the ubuntu-supplied libffcall
(libffcall1-dev 1.10+2.41-3)
clisp crashes on self-test.
when clisp is linked against the subversion cvs head libffcall,
all tests are passed.

[Taylor Venable (taylor-metasyntax)]

This problem is still there in exactly the same way in Karmic. The libffcall package version used in Karmic is the same. It still causes a segfault during self-tests for CLISP 2.48 (and CVS), and updating libffcall to CVS HEAD fixes it. It'd be extra cool if this package could be updated so I can build CLISP without having to pull down and update the supporting libraries as well.

[Christoph Egger (christoph-egger)]

libffcall CVS head failed in selftest for me because it misses some symbols -- seems there are in fact some risky changes happening.

I'm about to take over maintenance of the ffcall package in Debian and have already a CVS checkout, however I'm not sure I want to push anything into unstsable before squeeze yet.

[Christoph Egger (christoph-egger)]

https://savannah.gnu.org/bugs/?30124 just in case someone is interested

[sds (sds-gnu)]

it fails because you are trying to build it with shared libraries.
this is wrong.
most of the libffcall code is in the headers, the libraries are very small and they should be static.
it works for me just fine on both amd64 and i386 with the default configure options.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ffcall - 1.10+cvs20100619-2

---------------
ffcall (1.10+cvs20100619-2) unstable; urgency=low

  * Ship to unstable

ffcall (1.10+cvs20100619-1) experimental; urgency=low

  * New Upstream CVS snapshot (LP: #274951) (Closes: #504515)
    * Adding support for armel
  * Upload to experimental for now
 -- Christoph Egger <email address hidden> Sat, 26 Jun 2010 15:29:30 +0200

[sds (sds-gnu)]

clisp users report that the fix does NOT work while using the libffcall cvs does.
I strongly suspect that you are building libffcall with shared libraries.

[Faré (fahree)]

I see that the libffcall deb contains static libraries as well as dynamic ones. Is there a way to tell clisp to detect the latter and avoid the former?

[sds (sds-gnu)]

2011/6/5 Faré <email address hidden>:
> I see that the libffcall deb contains static libraries as well as
> dynamic ones. Is there a way to tell clisp to detect the latter and
> avoid the former?

http://article.gmane.org/gmane.comp.sysutils.autoconf.general:14289

workaround:
in the clisp build directory:

perl -p -i -e "s,-lavcall,/usr/lib/libavcall.a,g" `grep -I -r -l -- -lavcall .`
perl -p -i -e "s,-lcallback,/usr/lib/libcallback.a,g" `grep -I -r -l
-- -lcallback .`
make clean full check

--
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>