[Glass] FFI and C subsystems

[bruno buzzi brassesco]

James,

The new header files does not have any function declaration only 
"#includes" sentences.

Actually the entire new header files is:
#include "libssh.h"
#include "server.h"
#include "sftp.h"

So i do not see how a lookup will fail. But again maybe I'm missing 
something :)

regards,
bruno

On 26/11/2020 13:21, Smalltalk at JGFoster.net wrote:
> Bruno,
>
> If it works, then it may be fine, but I’ll be somewhat surprised if 
> that happens. My vague idea of the way a program interacts with a 
> shared library is as follows: (1) you ask the OS to load a library 
> (such as '/usr/lib64/libssh.so.4.4.0’ and the OS give you back a 
> ‘handle’ to that library; (2) you ask the OS to look up a function in 
> the library (you pass a string with the function name and you pass in 
> the previously returned handle) and the OS give you back a pointer to 
> a function in that library; (3) you use the pointer to call the 
> function. These are the steps that GemStone handles; you will have 
> previously created an object that encapsulates the function name, 
> parameter types, and return types.
>
> If you use the wrong header to generate a list of expected entry 
> points in a library, then the Smalltalk code will still be generated 
> and you can still load the library (step 1), but when you attempt to 
> lookup a function from library A in library B, the OS will fail at 
> step 2 since the function does not exist. I think that if you want to 
> call functions in two libraries, then you need to load both libraries 
> (step 1) and do the name lookup in the proper library (step 2).
>
> But my expertise in this area is several years old and was on the 
> Smalltalk side not on the VM side.
>
> James
>
>> On Nov 26, 2020, at 4:42 AM, bruno buzzi brassesco via Glass 
>> <glass at lists.gemtalksystems.com 
>> <mailto:glass at lists.gemtalksystems.com>> wrote:
>>
>> James,
>>
>> It seems that is possible to create a new header file and includes 2 
>> subsystems in the same GS Library.
>>
>> For example sftp_server_all.h:
>> #include "libssh.h"
>> #include "server.h"
>> #include "sftp.h"
>>
>> Then:
>> | header wrapperClass wrapper |
>> header := CHeader path: 'sftp_server_all.h'.
>> wrapperClass := header wrapperForLibraryAt:
>> '/usr/lib64/libssh.so.4.4.0'.
>> wrapperClass initializeFunctions.
>> UserGlobals at: wrapperClass name put: wrapperClass.
>>
>> Do you see any problem with this approach ?
>>
>> The new library generated all functions now i going to check if they 
>> work.
>> It should work i think ... (but again not a C expert -dealing with C 
>> again after 15 years-)
>>
>>
>>
>> regards,
>> Bruno
>>
>> On 9/10/2020 14:53, James Foster via Glass wrote:
>>> Bruno,
>>>
>>> My understanding is that the header parser follows all the #include 
>>> directives, so will find everything that could be called from C 
>>> code, including abs() in libc. But the process of calling a dynamic 
>>> library at runtime involves doing a name lookup of entry points *for 
>>> that library,* not for anything visible *to* the library, so libssh 
>>> does not have an abs() entry point. For that you would need a 
>>> reference to libc.
>>>
>>> The wrapper generator does not know what is actually in the given 
>>> library, just what functions are defined by all included header 
>>> files. So you have to do some selection on your own. One wrapper API 
>>> has a filter as an argument, and so for a library like GemStone C 
>>> Interface where all the functions begin with ‘gci’ we can filter to 
>>> only generate wrappers for those functions (it is unlikely that libc 
>>> has gci*() functions!).
>>>
>>> So, yes, you need to have a different library object for each 
>>> library so the system can do name lookups properly.
>>>
>>> James
>>>
>>>> On Oct 9, 2020, at 5:40 AM, Bruno Buzzi Brassesco via Glass 
>>>> <glass at lists.gemtalksystems.com 
>>>> <mailto:glass at lists.gemtalksystems.com>> wrote:
>>>>
>>>> Hi,
>>>> Maybe i'm wrong in some concepts here (not a C expert) but ...
>>>>
>>>> If a C library (libssh) has a subsystem (sftp) in order to create a 
>>>> GS wrapper i can do:
>>>>
>>>>     | header wrapperClass wrapper |
>>>>     header := CHeader path: '/usr/include/libssh/sftp.h'.
>>>>     wrapperClass := header wrapperForLibraryAt:
>>>>     '/usr/lib64/libssh.so.4.4.0'.
>>>>     wrapperClass initializeFunctions.
>>>>     UserGlobals at: wrapperClass name put: wrapperClass.
>>>>
>>>>
>>>> In this case I got all the functions of Libssh and also SFTP, so 
>>>> far so good.
>>>>
>>>> But what happens when there is more than one C subsystem?
>>>>
>>>> How can I generate only one GS wrapper for the original C library 
>>>> (libssh) and all its subsystems ?
>>>> Or I will have to create one wrapper per subsystem ?
>>>>
>>>> regards,
>>>> bruno
>>>> _______________________________________________
>>>> Glass mailing list
>>>> Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com>
>>>> https://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>>
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> https://lists.gemtalksystems.com/mailman/listinfo/glass
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com>
>> https://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/glass/attachments/20201126/5ef594a1/attachment.htm>