Re: LuaJIT + glXGetProcAddress

[Patrick Donnelly <batrick@...>]

On Sun, Mar 18, 2012 at 2:30 AM, Henk Boom <henk@henk.ca> wrote:
> On 2012-03-16, Mike Pall <mikelu-1203@mike.de> wrote:
>> Miles Bader wrote:
>>> Henk Boom <henk@henk.ca> writes:
>>> > Why would the luajit ffi be using a different library than the
>>> > linker/loader?
>>>
>>> Presumably luajit searches for libraries in "normal" locations.
>>
>> It just maps
>>   ffi.load("GL")
>> to:
>>   dlopen("libGL.so", RTLD_LAZY|RTLD_LOCAL)
>>
>> The FFI has no clue about the actual library paths on POSIX. It
>> simply relies on whatever dlopen() does, when called with a path
>> without a slash.
>>
>> I was always under the impression dlopen() behavior is the same as
>> implicit dependency loading via ELF headers. Apparently I'm wrong.
>> Maybe have a look at readelf -d and at the various environment
>> variables related to the dynamic loader.
>
> Interesting, I did a few tests on my system. dlopen("libGL.so"), gives
> the wrong library but dlopen("libGL.so.1") and dlopen("GL") (which I
> didn't know was valid..) give the right result.

Maybe look at strace output to see which libraries are being loaded.
The system call trace may also reveal other interesting details...

According to [1], it seems how file is interpreted if it does not
contain forward slashes is implementation defined. So, "GL" being
valid is not that surprising.

> It looks like I can get around this by using ffi.load("libGL.so.1")
> explicitly, but how portable is that to other linuxes?

I would guess you could manually choose the right library from the
`/sbin/ldconfig -p` output and pass that explicit pathname to
ffi.load. I don't know if that's a terrible idea or not. You can
always fallback to the generic ffi.load "GL" if that fails...

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/dlopen.html

-- 
- Patrick Donnelly