Andreas: Thanks for the replies. I did all of what you told me but I got
this error when trying to call the api:

'External library is invalid'

I even try to execute: ExternalLibrary initialize.

However, I am not convinced why this way is better than having module:
aString.

Disadvantages of this new way:

- I am "coupling" or "hardcoding" not only the library name but also the
location in the file system. Perhaps I rather this be automatically done by
FFI.

Advantages of this new way:

- I can add as many names or paths as I want to my library.

what do you think? can you help me with the advantages and disadvantages
from both alternatives?

Thanks!

Mariano



On Fri, May 1, 2009 at 5:44 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:

>
> On 01.05.2009, at 17:48, Andreas Raab wrote:
>
>  Bert Freudenberg wrote:
>>
>>> On 30.04.2009, at 23:55, Andreas Raab wrote:
>>>
>>>> Bert Freudenberg wrote:
>>>>
>>>>> On 30.04.2009, at 23:22, Mariano Martinez Peck wrote:
>>>>>
>>>>>>  However, you can of course manually do the "linking" step - in the
>>>>>>  ffi function declarations, use "libopendbx.so.1" as module instead
>>>>>>  of just "opendbx". This will then only work on Linux of course,
>>>>>>  since other Unix platforms use different schemes of versioning
>>>>>>  libraries.
>>>>>>
>>>>>>
>>>>>> Indeed. That's why I don't want to change the module name.
>>>>>>
>>>>> Well, you can also automate this "pseudo-linking". When starting up,
>>>>> just patch the right module name for the current platform into all the FFI
>>>>> declarations. That's how the OpenGL FFI bindings in Croquet work ...
>>>>>
>>>>
>>>> The way this is done is purely for historical reasons (and an
>>>> *extremely* bad example that should not be taught to anyone). The Right Way
>>>> to do this is to have a subclass of ExternalLibrary and implement the
>>>> class-side method #moduleName along the lines of:
>>>>
>>>> MyLibrary class>>moduleName
>>>> "Answer the module name to use for this library"
>>>> Smalltalk platformName = 'Win32' ifTrue:[^'MyLibrary32.dll'].
>>>> Smalltalk platformName = 'unix' ifTrue:[
>>>>   "check various locations and versions"
>>>>   #('/usr/lib/libMyLibrary.so'
>>>>     '/usr/lib/libMyLibrary.so.1'
>>>>     '/usr/lib/libMyLibrary.so.2'
>>>>     '/usr/share/libMyLibrary.so.1'
>>>>     '/usr/share/libMyLibrary.so.2') do:[:location|
>>>>        (FileDirectory fileExists: location) ifTrue:[^location].
>>>>   ].
>>>>   ^self error:'MyLibrary is not installed'
>>>>  ].
>>>>
>>>> etc.
>>>>
>>> Interesting. I thought the module in an FFI function declaration needed
>>> to be a literal string. How would you declare it to use MyLibrary instead?
>>>
>>
>> Define it in a subclass of ExternalLibrary. Functions defined in a
>> subclass of ExternalLibrary without a module: string use the moduleName from
>> the time the library is instantiated. The module: string was really only
>> intended for convenience such that one could declare FFI functions where it
>> is most convenient instead of having to use ExternalLibrary subclasses.
>>
>>
> That's a useful trick, thanks. Have not ever seen it before.
>
>
> - Bert -
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090503/5c65123a/attachment.htm