Re: LuaJIT + glXGetProcAddress

[Henk Boom <henk@...>]

Wow, thanks

henk@invincible-spell:~$ lsof | grep 'luajit.*GL'
luajit    2529       henk  mem       REG                8,5   372400
266276 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2
luajit    2529       henk  mem       REG                8,5  1025968
12016 /usr/lib/nvidia-current-updates/libGL.so.280.13

Why would the luajit ffi be using a different library than the linker/loader?

    henk

On 2012-03-15, Dimiter 'malkia' Stanev <malkia@gmail.com> wrote:
> Wild guess, but could it be linking to -lGL
>
> with GLFW and the non-ffi way of getting the info, you are relying on -lGL
>
> With FFI you are doing ffi.load( "GL" ) - is it possible that this loads
> a different library?
>
> Maybe you can put some options to LD_LIBRARY_PATH to debug, or printout
> the full names of the .so's being loaded (or just lsof?? not sure).
>
> http://linux.die.net/man/8/ld-linux
>
> On 3/15/2012 5:59 PM, Henk Boom wrote:
>> On 2012-03-15, Mike Pall<mikelu-1203@mike.de>  wrote:
>>> Henk Boom wrote:
>>>> I'm using LuaJIT 2.0.0-beta9 that I've checked out from git. My system
>>>> is Linux/x64 as well with a cpu that ubuntu lists as "Intel® Atom™ CPU
>>>> 330 @ 1.60GHz × 4"
>>>
>>> Well, I've got a Core2 E8400. But at this point CPU differences
>>> shouldn't matter at all: the JIT compiler isn't invoked and the
>>> interpreter is CPU-model-agnostic.
>>>
>>> And I've tested with both the released beta9 and git HEAD. Same
>>> (positive) result here.
>>>
>>>> I'm not sure what to try at this point. I know that I have support for
>>>> glCreateShader, since I've used it before in C/glut/glew programs. Is
>>>> there some other information I could capture that might make it easier
>>>> to debug the problem?
>>>
>>> Try to recompile everything with debugging turned on and then set
>>> a breakpoint at glCreateShader. You may have to wait for the
>>> library to load and/or use the internal symbol name. Check the
>>> argument it receives (in $rdi). Then set a breakpoint in the
>>> calling frame and check the result it returns (in $rax).
>>
>> Okay, so after trying to set a breakpoint I've figured out that the
>> ffi code is not actually calling glCreateShader. Printing the function
>> address returned from glXGetProcAddress from lua and from the
>> native-bound gl__glCreateShader tells me they have different
>> addresses. In particular, when I purposefully give glXGetProcAddress
>> an invalid name, it returns null in C, but from the ffi I always get
>> an address back.
>>
>> I added these lines to gl__glCreateShader:
>>
>>    printf("glXGetProcAddress: %p\n", glXGetProcAddress);
>>    printf("glXGetProcAddressARB: %p\n", glXGetProcAddressARB);
>>    printf("glCreateShader: %p\n", glCreateShader);
>>
>> and these to init.lua
>>
>>    print('glXGetProcAddress', libgl.glXGetProcAddress)
>>    print('glCreateShader', libgl.glXGetProcAddress('glCreateShader'))
>>
>> The output I get is a bit different every time, but here's an example:
>>
>> --------
>>
>> glfwInit	1
>> glfwOpenWindow	1
>> glfw version	2	6	0
>> opengl version 0.0
>>
>> this doesn't work
>> glXGetProcAddress	cdata<void (*())()>: 0x7f4a6c406d50
>> glCreateShader	cdata<void (*)()>: 0x7f4a6c1d6820
>> glCreateShader	0
>>
>> this does
>> glXGetProcAddress: 0x7f4a6fe09330
>> glXGetProcAddressARB: 0x7f4a6fe09440
>> glCreateShader: 0x7f4a70088060
>> glCreateShader	1
>> --------
>>
>> I'm not sure how those numbers make sense. Maybe I just don't
>> understand how these symbols are resolved at load/run-time, but I
>> would expect the lua-printed address of glXGetProcAddress to match
>> with the c-printed one.
>>
>>      henk
>>
>>
>
>