On Mon, Oct 29, 2018 at 5:49 PM tim Rowledge <tim@rowledge.org> wrote:


> On 2018-10-29, at 12:26 PM, Bert Freudenberg <bert@freudenbergs.de> wrote:
>
> On Sat, Oct 27, 2018 at 4:42 PM tim Rowledge <tim@rowledge.org> wrote:
> Trying this out on a Raspberry Pi (obviously).
> First major problem is that
>
> OGLUnix>>openGLLibraryName
>         ^Smalltalk osVersion = 'linux'
>                 ifTrue: ['libGL.so.1']
>                 ifFalse: ['GL']

It's actually a bit worse - the osVersion returned by Raspbian is 'linux-gnu' - so I tried changing that to
openGLLibraryName
        ^(Smalltalk osVersion beginsWith: 'linux')
                ifTrue: ['libGL.so.1']
                ifFalse: ['GL']
which got a bit further.

> has a #'' (apparently a ByteSymbol with just char value 0 in it) at the end of the method ; which of course a BlockClosure does not understand.
>
[snip]
>
> The" module: '#openGLLibraryName'>" looks a bit odd to me... shouldn't that have been recompiled to use the real library name?
>
> Yes, but it doesn't change the source code. Follow the senders of openGLLibraryName to see the magic.

OK, so it's supposed to send #openGLLibraryName at some startup point. Very clever.

Yep, in OpenGL>>initialize it calls "self privateInstallLibrary: self openGLLibraryName." which patches the library name into all compiled FFI methods.

Unfortunately it appears something else goes wrong pretty quickly and OGLExtManager>>#loadExtension: uses glExtGetProcAddress: which even decompiled says
        <cdecl: ulong 'glXGetProcAddressARB' (char*) module: 'GL'>
Which doesn't seem right. Should it also use the #openGLLibraryName thing?

Ah, that seems to be an actual bug.

#privateInstallLibrary: does not go into the subclasses. In OGLWin32, that method has the correct 'opengl32.dll'  module.  OGLMacOSX uses a different mechanism entirely. And OGLUnix relies on "GL" linking to the right thing. 

So I'd say in privateInstallLibrary: we need to patch both OpenGL and OGLUnix.

- Bert -