[cffi-devel] New foreign library interface

[Frank Goenninger - PRION Consulting]

Answering to myself - one more case of "you better read before  
writing"... See below.

Am 07.01.2006 um 21:56 schrieb Frank Goenninger - PRION Consulting:

>
> Am 07.01.2006 um 20:25 schrieb Luís Oliveira:
>
>> On 2006-jan-07, at 16:52, Frank Goenninger - PRION Consulting wrote:
>>>> We don't really search for the library ourselves. dlopen() takes  
>>>> care of that for us. It was just an example.
>>>
>>> Ah. So, if you want to make dlopen() handle all searching, then  
>>> you'd have to extend the respective environment variable with  
>>> user-supplied search paths. Which brings us to ? Yes, platform- 
>>> dependent putenv() calls or whatever the Lisp implementation's  
>>> way is to set an env var. Or do I misunderstand still somethimng  
>>> here?
>>
>> Hmm, I'm not sure what you mean. What happens is that, if dlopen()  
>> can't find the library, we try finding it in one of the  
>> directories in the cffi:*foreign-library-directories* list.
>
> I assumed you would do that. Now you've confirmed that. Thanks.
>
> dlopen() of course does not always return a real error if it  
> couldn't find the lib (in some cases I had a return value of NULL  
> which in some cases meant that there was an error and in some cases  
> not) . I had cases (on HP-UX, where you use shl_load() because  
> there's no dlopen() in this OS) where I had to examine errno (and  
> on other OSes, where available, with dlerror() ...) to find out  
> what really happened.
>
> Thanks again - having talked/written that much now I figure I  
> should start supporting you and begin coding that stuff... Will  
> look for the source code.

I figured by reading the different cffi-XXX.lisp files that you rely  
on the different implementations' functions to handle all these  
things. Ok, now that I know that I better shut up... I assumed from  
your messages that you really call dlopen() and such directly - on  
second thought, well, I see that is useless...

Frank