I noticed that while avcall/tests.c contains 2 long
(controlled by #ifdef HAVE_LONGLONG), the actual run of
i686-pc-linux-gnu did not use them
Maybe HAVE_LONGLONG is not defined for AVCALL?? This
starts to look
like a bug that I should report to ffcall.sf.net
-- Oops, wasn't ffcall once a distinct package on SF?!?
Yet the entries I found on fsf.org and freshmeat.net
all redirect to Bruno, without mention of a bugtracker.
If ffcall is not hosted within clisp, then I suggest to
add the category "ffcall" to the clisp/sf bugtracker.
snippet of minitests.out
The longlong tests should have appeared between the two.
The bug is as follows: avcall/config.log says
#define HAVE_LONG_LONG 1
while tests.c contains
As a result, the 64bit functionality of ffcall goes
CLISP's own build-gcc/config.log contains
| #define HAVE_LONG_LONG 1
| #define HAVE_LONGLONG
but it's not yet used at the time ffcall is built.
Note that clisp does not use av_longlong (available in
suppose CLISP's code was not revised when ffcall
Log in to post a comment.