[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT FFI only bindings for glfw, OpenCL, OpenGL
- From: Henk Boom <henk@...>
- Date: Wed, 26 Jan 2011 13:51:28 -0500
On 26 January 2011 05:15, David Given <firstname.lastname@example.org> wrote:
> On 26/01/11 07:00, Henk Boom wrote:
>> They don't exist in the .dll, or they don't exist in the header file?
> Having worked with OpenGL extensions (mostly on egl), the answer to this
> question is: both, possibly neither.
> The prototypes for the extension functions are set in stone by
> Khronos[*]. It's perfectly acceptable for the application to declare its
> own prototypes (or even have its own copies of the header files, copied
> from Khronos itself). It gets the function using *GetProcAddress(),
> casts it to the appropriate type, and then it can call it. As a result,
> it's completely undefined where the function itself resides. One
> possible implementation is to have *GetProcAddress() dlopen() a shared
> library with the given name so that the extensions get loaded on demand...
> [*] ...eg:
> GL_APICALL void GL_APIENTRY glExtGetShadersQCOM (GLuint *shaders, GLint
> maxShaders, GLint *numShaders);
> The GL_APICALL and GP_APIENTRY macros can be defined by the platform to
> provide platform-specific tweaks to the ABI. Normally GL_APICALL is
> defined to 'extern' or '__declspec(dllimport)' and GL_APIENTRY to a
> compiler-specific calling convention specifier like '__stdcall' or
> '__ccall'. Which of course means that the ABI can vary drastically
> depending on how your OpenGL library has been built, even on a single
> platform, which means that maintaining an FFI-compatible repository of
> function prototypes isn't adequate.
> Fun, eh?
I learned something new, thanks for the info!
- LuaJIT FFI only bindings for glfw, OpenCL, OpenGL, malkia
- Re: LuaJIT FFI only bindings for glfw, OpenCL, OpenGL, CrazyButcher
- Re: LuaJIT FFI only bindings for glfw, OpenCL, OpenGL, Henk Boom
- Re: LuaJIT FFI only bindings for glfw, OpenCL, OpenGL, David Given