Hi Joe,
Thanks for the report.
I will fix the double definition of ffi_sint. I regularly build TXR as C++, but I didn't test the combination "g++ and libffi missing"!
The configure script currently doesn't test for anything other than whether -lffi is needed for linking; the test program is hard coded to #include <ffi.h>. That's the include syntax used in all the libffi documentation, so I didn't bother detecting the location.
TXR hasn't used anything so far that would require a big hammer like pkg-config. (Is it really called pkg_config on Arch, by the way?)
In the future, hopefully, we can avoid bogging down TXR with dependencies by using this nice FFI I developed.
I will change the test so it tries things exactly as it does now, and then falls back on pkg-config if those approaches fail to compile and link the test program.
Cheers ...
On 04.07.2017 14:37, Joe Eib wrote:
After receiving the following error during 'make_tests'
...
TXR tests/017/
glob-carray.tl-> tst/tests/017/glob-carray.out
./txr: unhandled exception of type error:
./txr: ffi-type-compile: unrecognized type specifier: closure
./txr: during evaluation at tests/017/
glob-carray.tl:30 of form [mapcar ffi-type-compile
'(str int closure
(ptr-out glob-t))]
make: *** [Makefile:356: tst/tests/017/glob-carray.out] Error 1
After a little digging I noticed that your configure script fails to detect my libffi because Arch Linux installs libffi.h in a nonstandard location. I don't know exactly what you're testing for there on line 2845 of configure but why not just use 'pkg_config --exists libffi' or the PKG_CHECK_EXISTS macro and then get the compiler and linker flags directly from pkg_config?
Also, when I was trying to find the source of the issue, I compiled txr with g++ just for the hell of it and discovered that ffi_type_sint is declared twice on lines 141 and 144 which throws an error in g++.
(text/plain)