Re: [LuaJIT] JIT'd Code Causing Segfaults on Linux x86?

[Dimiter 'malkia' Stanev <malkia@...>]

It could be tedious, yes, and OpenGL's xxxGetProcAddress() functions do 
work only when the context is created, but here is quick workaround for 
Windows:

   ffi.cdef[[
       void* wglGetProcAddress(const char*);
       typedef GLuint (*pglCreateShader)(GLenum);
   ]]
   local glCreateShader = ffi.new( "pglCreateShader", 
gl.wglGetProcAddress( "glCreateShader" ) )
   print(glCreateShader(gl.GL_VERTEX_SHADER))

you would need to change wglGetProcAddress to glxGetProcAddress() or 
something more appropriate.

I think someone posted OpenGL ffi bindings that took care of this, have 
to dig the archives to find them though.

I'm actually thinking of fully moving to OpenGL ES 2 on the desktop, 
through wrappers such as qemu's gles-libs (dgles2 for all platforms), or 
angleproject (but it's Direct3D, and would not cooperate well), or on 
NVIDIA cards to enable it through the extensions.

This way the whole API is there that I need (I'm leaning more mobile for 
the stuff I want to do).

On 5/3/2012 2:05 PM, Alex wrote:
> On Thu, May 3, 2012 at 8:28 AM, Mike Pall <mikelu-1205@mike.de
> <mailto:mikelu-1205@mike.de>> wrote:
>
>     Alex wrote:
>      > The FFI headers I'm using were parsed from GLEW on my Windows
>     x64, which is
>      > probably why they are there. I'll try re-processing the headers
>     tomorrow in
>      > Linux and see if it clears up.
>
>     Umm, you may get into trouble if you process headers on 64 bit and
>     use them on 32 bit, anyway. That is, unless you're very, very
>     careful to abstract out all the word size dependencies with
>     ptrdiff_t, size_t, intptr_t, uintptr_t etc. And then there are
>     some libraries which have incompatible APIs on each platform,
>     hidden behind a mess of macros ...
>
> Yea, hence why I was going to reprocess them.
>
>      > gllib = setmetatable({}, {__index=function(self,k) return
>     lookup[k] and
>      > glew[lookup[k]] or gl[k]})
>      >
>      > I'm not quite sure how else to redirect them short of using the GLEW
>      > internal functions everywhere.
>
>     The first thing that comes to mind is to cache the lookup result
>     in the table.
>
>     But the real question is why do you use GLEW at all? This may be
>     convenient for C/C++, but the LuaJIT FFI offers lots more magic to
>     automate all of that. There are several FFI GL bindings out there,
>     and someone must have solved that problem nicely by now.
>
>
> Mostly because it was an easy(er) way to use OpenGL extensions, namely
> shaders, which I haven't seen in existing solutions. Though I guess with
> all the trouble this is giving me it may be worth it to start using the
> glext.h file...