foreign-symbol-pointer should work on Corman, yes. Hopefully defcfun-ing an unexisting function won't yield an error.
Some alternative ideas, if that doesn't work:
1. Handle/ignore the defcfun error. 2. Implement foreign-funcall on Corman Lisp (src/cffi-corman.lisp has some suggestions on how to do that) 3. Ask the Corman Lisp developers to implement foreign-funcall(-pointer). 4. Ignore the problem until #2 or #3 are implemented. (Possibly not a big issue since Corman Lisp is not as widely used as other Lisps.)
Cheers, Luís
On Mon, May 29, 2017, 03:25 Anton Vodonosov avodonosov@yandex.ru wrote:
Luis, thanks for the response
29.05.2017, 05:18, "Luís Oliveira" luismbo@gmail.com:
You can look up both functions using foreign-symbol-pointer to decide which one to call. You'd usually call the right one using foreign-funcall-pointer, but perhaps you can defcfun both and call the right one based on the lookup.
Will that work on Corman?
defcfun-ing non-existent functions will yield runtime warnings on some
implementations
(notably SBCL) so perhaps you might want to implement both the
foreign-funcall-pointer
and defcfun approaches and conditionalise them accordingly.
BTW, CMUCL fails with error in this case.
HTH, Luís
On Mon, May 29, 2017, 02:56 Anton Vodonosov avodonosov@yandex.ru
wrote:
Hello,
OpenSSL renamed function SSLeay to OpenSSL_version_num. So, so depending on what version of library we work with we need to call either SSLeay or OpenSSL_version_num.
What is the best way to do it?
The following is one approach:
(or (ignore-errors (cffi:foreign-funcall "OpenSSL_version_num" :long)) (ignore-errors (cffi:foreign-funcall "SSLeay" :long)))
but it won't work on Corman Lisp because it doesn't support cffi:foreign-funcall.
I would like to be fully portable. Is there a better way?
Best regards,
- Anton