Thread overview
ssll - simple shared library loader
Jan 05
Oleg B
Jan 10
Oleg B
Jan 06
user1234
Jan 10
Oleg B
January 05
It's analog of bindbc, but without need write boilerplate code.
May be bindbc is designed for another cases, but I don't understand need writing triple definition for one function (pointer, loading, wrap-function).
ssll betterC compatible too, and tested on windows (x86) and linux (x86, ARM).

package: http://code.dlang.org/packages/ssll
github: https://github.com/deviator/ssll

Example usage:

Mosquitto binding and wrapper
https://github.com/deviator/mosquittod/blob/master/source/mosquittod/api/load.d

libsystemd binding
https://github.com/deviator/sdutil/blob/master/source/systemd/daemon.d

I think somebody can find it handy.
January 06
On Sunday, 5 January 2020 at 23:23:48 UTC, Oleg B wrote:

Nice work! One thing I would recommend, though, is that you not bake in extern(C). Some libraries require extern(System) (because they're stdcall on Windows and cdecl everywhere else).

There's also the issue with the Windows stdcall name-mangling scheme in 32-bit libraries, where the symbol name incorporates the size of the function parameters. Some stdcall libraries (like OpenGL) are configured to compile with the unmangled names, but others (like FreeImage) are not and require transforming the symbol name into the mangled form.

So to be robust, you'll want to implement support for both into SSLL.

> It's analog of bindbc, but without need write boilerplate code.
> May be bindbc is designed for another cases, but I don't understand need writing triple definition for one function (pointer, loading, wrap-function).

There are only two declarations required for the dynamic bindings in BindBC: an alias and a pointer. And of course the loader is separate. The reason is historical. When I was working on the earliest version of Derelict back in 2004, we didn't have all the fancy compile-time features we have now. I (and a couple of contributors) tried doing it by declaring the function pointers without aliases, but we ran into a couple of issues and settled for taking the alias + pointer approach. (It's been so long that I can't recall what the issues were).

In the 4th iteration of Derelict (the bindings in DerelictOrg on github), I experimented with UDAs and single function declarations that I could generate static and dynamic bindigs with. But I was still mixing in the alias and pointer declarations for the dynamic bindings and could never figure out a way to distinguish between them during introspection. I posted about it here on the forums and no one had an answer, so I gave up.

So bindbc is implemented the way it is because that's the way I've done it for almost 16 years.
January 06
On Sunday, 5 January 2020 at 23:23:48 UTC, Oleg B wrote:
> It's analog of bindbc, but without need write boilerplate code.
> May be bindbc is designed for another cases, but I don't understand need writing triple definition for one function (pointer, loading, wrap-function).
> ssll betterC compatible too, and tested on windows (x86) and linux (x86, ARM).
>
> package: http://code.dlang.org/packages/ssll
> github: https://github.com/deviator/ssll
>
> Example usage:
>
> Mosquitto binding and wrapper
> https://github.com/deviator/mosquittod/blob/master/source/mosquittod/api/load.d
>
> libsystemd binding
> https://github.com/deviator/sdutil/blob/master/source/systemd/daemon.d
>
> I think somebody can find it handy.

Nice, I like this project and how it solves the problem stated, i.e the 3 versions.
January 06
Am 06.01.2020 um 00:23 schrieb Oleg B:
> It's analog of bindbc, but without need write boilerplate code.
> May be bindbc is designed for another cases, but I don't understand need writing triple definition for one function (pointer, loading, wrap-function).
> ssll betterC compatible too, and tested on windows (x86) and linux (x86, ARM).
> 
> package: http://code.dlang.org/packages/ssll
> github: https://github.com/deviator/ssll
> 
> Example usage:
> 
> Mosquitto binding and wrapper
> https://github.com/deviator/mosquittod/blob/master/source/mosquittod/api/load.d 
> 
> 
> libsystemd binding
> https://github.com/deviator/sdutil/blob/master/source/systemd/daemon.d
> 
> I think somebody can find it handy.

Just throwing this in as a possible API alternative/addition - I've written something similar with the goal to make it work transparently with existing static bindings: https://code.dlang.org/packages/dynamic

It uses a mixin to specify the module(s) containing the declarations instead of a UDA:


mixin dynamicBinding!(somelib) _somelib;

void main()
{
    _somelib.loadBinding(["somelib.so"]);

    import somelib : foo;
    foo();
}
January 10
On Monday, 6 January 2020 at 04:32:25 UTC, Mike Parker wrote:
> On Sunday, 5 January 2020 at 23:23:48 UTC, Oleg B wrote:
>
> Nice work! One thing I would recommend, though, is that you not bake in extern(C). Some libraries require extern(System) (because they're stdcall on Windows and cdecl everywhere else).
>
> So to be robust, you'll want to implement support for both into SSLL.

Thanks for the advice! I will continue work on ssll and will try implement this feature.

> There are only two declarations required for the dynamic bindings in BindBC: an alias and a pointer. And of course the loader is separate. The reason is historical. When I was working on the earliest version of Derelict back in 2004, we didn't have all the fancy compile-time features we have now. I (and a couple of contributors) tried doing it by declaring the function pointers without aliases, but we ran into a couple of issues and settled for taking the alias + pointer approach. (It's been so long that I can't recall what the issues were).

Thanks for the clarification and thanks for Derelict bindings!
January 10
On Monday, 6 January 2020 at 10:04:38 UTC, Sönke Ludwig wrote:
> I've written something similar with the goal to make it work transparently with existing static bindings: https://code.dlang.org/packages/dynamic
>
> It uses a mixin to specify the module(s) containing the declarations instead of a UDA

Interesting solution. Do you plain implement betterC compatible?