<p dir="ltr">That solution looks interesting. Does it work? </p>
<p dir="ltr">I'm not sure about the defcfun error handling on CMUCL, sorry. I'd have to try it out. </p>
<p dir="ltr">Cheers, <br>
Luís </p>
<br><div class="gmail_quote"><div dir="ltr">On Mon, May 29, 2017, 03:48 Anton Vodonosov <<a href="mailto:avodonosov@yandex.ru">avodonosov@yandex.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
29.05.2017, 05:42, "Luís Oliveira" <<a href="mailto:luismbo@gmail.com" target="_blank">luismbo@gmail.com</a>>:<br>
> foreign-symbol-pointer should work on Corman, yes.<br>
<br>
If so, maybe this is the best solution?<br>
<br>
    (if (cffi:foreign-symbol-pointer "OpenSSL_version_num")<br>
        (cffi:defcfun ("OpenSSL_version_num" ssleay) :long)<br>
        (cffi:defcfun ("SSLeay" ssleay) :long))<br>
<br>
<br>
> Hopefully defcfun-ing an unexisting function won't yield an error.<br>
><br>
> Some alternative ideas, if that doesn't work:<br>
><br>
> 1. Handle/ignore the defcfun error.<br>
<br>
At what time? (compile, load time, invocation time?)<br>
I was thinking about handling defcfun error but can't understand how to do that correctly?<br>
<br>
> 2. Implement foreign-funcall on Corman Lisp (src/cffi-corman.lisp has some suggestions on how to do that)<br>
> 3. Ask the Corman Lisp developers to implement foreign-funcall(-pointer).<br>
> 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.)<br>
><br>
> Cheers,<br>
> Luís<br>
><br>
> On Mon, May 29, 2017, 03:25 Anton Vodonosov <<a href="mailto:avodonosov@yandex.ru" target="_blank">avodonosov@yandex.ru</a>> wrote:<br>
>> Luis, thanks for the response<br>
>><br>
>> 29.05.2017, 05:18, "Luís Oliveira" <<a href="mailto:luismbo@gmail.com" target="_blank">luismbo@gmail.com</a>>:<br>
>>> You can look up both functions using foreign-symbol-pointer<br>
>>> to decide which one to call. You'd usually call the right one using<br>
>>> foreign-funcall-pointer, but perhaps you can defcfun both and<br>
>>> call the right one based on the lookup.<br>
>><br>
>> Will that work on Corman?<br>
>><br>
>>><br>
>>> defcfun-ing non-existent functions will yield runtime warnings on some implementations<br>
>>> (notably SBCL) so perhaps you might want to implement both the foreign-funcall-pointer<br>
>>> and defcfun approaches and conditionalise them accordingly.<br>
>><br>
>> BTW, CMUCL fails with error in this case.<br>
>><br>
>>><br>
>>> HTH,<br>
>>> Luís<br>
>>><br>
>>> On Mon, May 29, 2017, 02:56 Anton Vodonosov <<a href="mailto:avodonosov@yandex.ru" target="_blank">avodonosov@yandex.ru</a>> wrote:<br>
>>>> Hello,<br>
>>>><br>
>>>> OpenSSL renamed function SSLeay to OpenSSL_version_num.<br>
>>>> So, so depending on what version of library we work with we<br>
>>>> need to call either SSLeay or OpenSSL_version_num.<br>
>>>><br>
>>>> What is the best way to do it?<br>
>>>><br>
>>>> The following is one approach:<br>
>>>><br>
>>>> (or (ignore-errors<br>
>>>>       (cffi:foreign-funcall "OpenSSL_version_num" :long))<br>
>>>>     (ignore-errors<br>
>>>>       (cffi:foreign-funcall "SSLeay" :long)))<br>
>>>><br>
>>>> but it won't work on Corman Lisp because it doesn't<br>
>>>> support cffi:foreign-funcall.<br>
>>>><br>
>>>> I would like to be fully portable. Is there a better way?<br>
>>>><br>
>>>> Best regards,<br>
>>>> - Anton<br>
</blockquote></div>