libffcall should now be based on the cvs head, not 1.10 tar ball
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| ffcall (Ubuntu) |
Undecided
|
Unassigned |
Bug Description
Binary package hint: libffcall1
package libffcall is based on the 1.10 tar ball from santafe.
this is obsolete as per http://
you should get the sources from the cvs as described in
https:/
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.
Related branches
sds (sds-gnu) wrote : | #1 |
Taylor Venable (taylor-metasyntax) wrote : | #2 |
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) wrote : | #3 |
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) wrote : | #4 |
https:/
sds (sds-gnu) wrote : | #5 |
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) wrote : | #6 |
This bug was fixed in the package ffcall - 1.10+cvs20100619-2
---------------
ffcall (1.10+cvs201006
* Ship to unstable
ffcall (1.10+cvs201006
* 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
Changed in ffcall (Ubuntu): | |
status: | New → Fix Released |
sds (sds-gnu) wrote : | #7 |
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.
Changed in ffcall (Ubuntu): | |
status: | Fix Released → Confirmed |
Faré (fahree) wrote : | #8 |
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) wrote : Re: [Bug 274951] Re: libffcall should now be based on the cvs head, not 1.10 tar ball | #9 |
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://
workaround:
in the clisp build directory:
perl -p -i -e "s,-lavcall,
perl -p -i -e "s,-lcallback,
-- -lcallback .`
make clean full check
--
Sam Steingold <http://
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.