2011/6/5 Faré 274...@bugs.launchpad.net:
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
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?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
--
You received this bug notification because you are a member of
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
** Branch linked: lp:debian/experimental/ffcall
--
libffcall should now be based on the cvs head, not 1.10 tar ball
https://bugs.launchpad.net/bugs/274951
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
https://savannah.gnu.org/bugs/?30124 just in case someone is interested
** Bug watch added: GNU Savannah Bug Tracker #30124
http://savannah.gnu.org/bugs/?30124
--
libffcall should now be based on the cvs head, not 1.10 tar ball
https://bugs.launchpad.net/bugs/274951
You received this bug
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.
--
libffcall should now
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
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
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.
--
libffcall should now be based on the cvs head, not 1.10 tar ball
10 matches
Mail list logo
