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
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