[cffi-devel] New foreign library interface

[Frank Goenninger - PRION Consulting]

Am 07.01.2006 um 02:20 schrieb Luís Oliveira:

> On 2006-jan-06, at 20:13, Frank Goenninger - PRION Consulting wrote:
>>>   (define-foreign-library opengl
>>
>> Is opengl then interned as a symbol (in which package) ? Or a  
>> keyword ?
>
> Yes, the current package. You can use a keyword if you prefer.  
> Probably better to use a normal symbol though.

Yes, I agree.

>> This is completely platform dependant (as you probably know ;-)
>> So, if you want to handle all the cases in CFFI then there are
>> at least the following cases in addition:
>>
>> HP-UX:
>>   - SHLIB_PATH env var
> [etc..]
>
> 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?

>> What I am missing is the support for handling multiple versions of  
>> foreign libs. It should be possible to state which version to load  
>> if more than one version is installed or if a certain version is  
>> required. I know this no trivial task as the version naming of  
>> libs is not unified. Also, there has to some means of specifying  
>> what to do if the requested lib version is not available. Some  
>> fallback behaviour like :load-newest or :signal-error or :load- 
>> newest-if-higher-version ...
>
> Would using :OR be enough? (:or "libFoo.so.2.2" "libFoo.so.2.1"  
> "libFoo.so.2" "libFoo.so") or something like that?

Yes, if left-to-right search order is maintained and this use case  
documented as an example for how to deal with versions ;-)

>
> Also, in that private e-mail you sent me you mention that USE- 
> FOREIGN-LIBRARY should evaluate its argument. But, the purpose of  
> this macro is to wrap LOAD-FOREIGN-LIBRARY in an EVAL-WHEN  
> basically because of CMUCL which needs the libraries loaded at  
> compile-time.

Yes, I now also figured that it's OK not to evaluate because of that  
case. I wasn't aware that CMUCL needs this.

Thanks for the reply!

Cheers
   Frank