Smalltalk › Squeak › Squeak - Dev

OGLUnixX11LE >> glPixelStorei: with:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Squeak - Dev mailing list

OGLUnixX11LE >> glPixelStorei: with:

Hi folks,

I am stepping through the OpenGL example, getting my head wrapped around it.

First thing is in OGLUnix openGLLibraryName I had to make a change for Smalltalke osVersion to handle 'linux-gnu'.

openGLLibraryName
^((Smalltalk osVersion = 'linux') | (Smalltalk osVersion = 'linux-gnu'))
ifTrue: ['libGL.so.1']
ifFalse: ['GL']

All well and good.

Also, as pre-amble, I am able to set debug level via primitive call with:

OpenGL primitiveSetVerboseLevel:5

with no exception/error.

My immediate concern is in OGLUnixX11LE >> glPixelStorei:with:

glPixelStorei: pname with: param
"This method was automatically generated."
"void glPixelStorei(GLenum pname, GLint param);"
<apicall: void 'glPixelStorei' (ulong long) module: '#openGLLibraryName'>
^self externalCallFailed

That argument module:'#openGLLibraryName' smells like an error, as if it should have been replaced by something with 'libGL.so.1'

Well, I manually replaced it in that method with the same result.

I downloaded the latest FFI-Examples package and the FFI-Unix-Examples is empty, so I cannot infer from that.

Is there a way I can search the image for all the <apicall: pragmas ? I may be able to find one that works and start from there.

thanks in advance.

Beckmann, Tom

Re: OGLUnixX11LE >> glPixelStorei: with:

Hi there!

Replacing the whole #openGLLibraryName method with a simple
^ 'GL'
should work, as long as you adapt your LD_LIBRARY_PATH to include the arch specific libraries. For example adding
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/"
in your squeak.sh before the vm gets started should make sure that the image finds libgl*. Of course, if your libgl.so.1 is not found under that path, adjust accordingly.

Alternatively, you can also specify the absolute path to the library, e.g.
^ '/usr/lib/x86_64-linux-gnu/libGL.so'
which may be a safer option to start from if you're having troubles getting it to run.

For the apicall:'s, if you inspect the byte codes of the method, you will in fact notice that is has already been replaced for you. This happens in OpenGL>>#privateInstallLibrary:, but only updates the method's bytecode, not its source code (which is good, because otherwise this would end up in commits or your changes file).

Best,
Tom
________________________________________
From: Squeak-dev <[hidden email]> on behalf of gettimothy via Squeak-dev <[hidden email]>
Sent: Friday, May 8, 2020 9:23:48 PM
To: squeak-dev
Subject: [squeak-dev] OGLUnixX11LE >> glPixelStorei: with:

Hi folks,

I am stepping through the OpenGL example, getting my head wrapped around it.

First thing is in OGLUnix openGLLibraryName I had to make a change for Smalltalke osVersion to handle 'linux-gnu'.

openGLLibraryName
^((Smalltalk osVersion = 'linux') | (Smalltalk osVersion = 'linux-gnu'))
ifTrue: ['libGL.so.1']
ifFalse: ['GL']

All well and good.

Also, as pre-amble, I am able to set debug level via primitive call with:

OpenGL primitiveSetVerboseLevel:5
with no exception/error.

My immediate concern is in OGLUnixX11LE >> glPixelStorei:with:

glPixelStorei: pname with: param
"This method was automatically generated."
"void glPixelStorei(GLenum pname, GLint param);"
<apicall: void 'glPixelStorei' (ulong long) module: '#openGLLibraryName'>
^self externalCallFailed

That argument module:'#openGLLibraryName' smells like an error, as if it should have been replaced by something with 'libGL.so.1'

Well, I manually replaced it in that method with the same result.

I downloaded the latest FFI-Examples package and the FFI-Unix-Examples is empty, so I cannot infer from that.

Is there a way I can search the image for all the <apicall: pragmas ? I may be able to find one that works and start from there.

thanks in advance.

Levente Uzonyi

Re: OGLUnixX11LE >> glPixelStorei: with:

In reply to this post by Squeak - Dev mailing list

Hi Tim,

On Fri, 8 May 2020, gettimothy via Squeak-dev wrote:

> Hi folks,
>
> I am stepping through the OpenGL example, getting my head wrapped around it.
>
> First thing is in OGLUnix openGLLibraryName I had to make a change for Smalltalke osVersion to handle 'linux-gnu'.
>
>
>
> openGLLibraryName
> ^((Smalltalk osVersion = 'linux') | (Smalltalk osVersion = 'linux-gnu'))
> ifTrue: ['libGL.so.1']
> ifFalse: ['GL']
>
>
>
> All well and good.
>
> Also, as pre-amble, I am able to set debug level via primitive call with:
>
> OpenGL primitiveSetVerboseLevel:5
>
> with no exception/error.
>
>
>
> My immediate concern is in OGLUnixX11LE >> glPixelStorei:with:
>
>
> glPixelStorei: pname with: param
> "This method was automatically generated."
> "void glPixelStorei(GLenum pname, GLint param);"
> <apicall: void 'glPixelStorei' (ulong long) module: '#openGLLibraryName'>
> ^self externalCallFailed
>
>
> That argument module:'#openGLLibraryName' smells like an error, as if it should have been replaced by something with 'libGL.so.1'
>
> Well, I manually replaced it in that method with the same result.

IIRC the method is modified but the source code remains the same. If you
click on the source button of the browser and choose decompile, you should
see that the library name was replaced.

Levente

>
> I downloaded the latest FFI-Examples package and the FFI-Unix-Examples is empty, so I cannot infer from that.
>
>
> Is there a way I can search the image for all the <apicall: pragmas ? I may be able to find one that works and start from there.
>
> thanks in advance.
>
>
>
>
>
>
>

codefrau

Re: OGLUnixX11LE >> glPixelStorei: with:

In reply to this post by Beckmann, Tom

On Sat, May 9, 2020 at 12:05 AM Beckmann, Tom <[hidden email]> wrote:

Hi there!

Replacing the whole #openGLLibraryName method with a simple
^ 'GL'
should work, as long as you adapt your LD_LIBRARY_PATH to include the arch specific libraries. For example adding
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/"
in your squeak.sh before the vm gets started should make sure that the image finds libgl*. Of course, if your libgl.so.1 is not found under that path, adjust accordingly.

Alternatively, you can also specify the absolute path to the library, e.g.
^ '/usr/lib/x86_64-linux-gnu/libGL.so'
which may be a safer option to start from if you're having troubles getting it to run.

'libGL.so' typically is installed by the opengl dev package as a symlink to 'libGL.so.1'. The user package installs 'libGL.so.1' and will *not* be found by the VM if you just specify 'GL' because the VM will only automatically try the '.so' suffix but not '.so.1'.

That is why 'libGL.so.1' is indeed the correct value to be returned from openGLLibraryName on Linux.

For the apicall:'s, if you inspect the byte codes of the method, you will in fact notice that is has already been replaced for you. This happens in OpenGL>>#privateInstallLibrary:, but only updates the method's bytecode, not its source code (which is good, because otherwise this would end up in commits or your changes file).

Yep. As Levente mentioned, you need to switch your browser to show decompiled code to see the actual methods being executed.

You will also see that apicall has been replaced by cdecl which is the right calling convention on Linux.

- Vanessa -

Best,
Tom

Beckmann, Tom

Re: OGLUnixX11LE >> glPixelStorei: with:

Hi Vanessa,

thank you for clarifying! Do you know if there's any reason to keep the conditional asking for the osVersion to either return 'GL' or 'libgl.so.1'? In its current state it is broken on most linux systems I tested on (mainly Ubuntu-based), but I was wondering whether the correct fix would be to adapt it to the correct matching string 'linux-gnu' or just have it return 'libgl.so.1' always.

Best,
Tom
________________________________________
From: Squeak-dev <[hidden email]> on behalf of Vanessa Freudenberg <[hidden email]>
Sent: Sunday, May 10, 2020 3:19:00 AM
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] OGLUnixX11LE >> glPixelStorei: with:

On Sat, May 9, 2020 at 12:05 AM Beckmann, Tom <[hidden email]<mailto:[hidden email]>> wrote:
Hi there!

Replacing the whole #openGLLibraryName method with a simple
^ 'GL'
should work, as long as you adapt your LD_LIBRARY_PATH to include the arch specific libraries. For example adding
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/"
in your squeak.sh before the vm gets started should make sure that the image finds libgl*. Of course, if your libgl.so.1 is not found under that path, adjust accordingly.

Alternatively, you can also specify the absolute path to the library, e.g.
^ '/usr/lib/x86_64-linux-gnu/libGL.so'
which may be a safer option to start from if you're having troubles getting it to run.

'libGL.so' typically is installed by the opengl dev package as a symlink to 'libGL.so.1'. The user package installs 'libGL.so.1' and will *not* be found by the VM if you just specify 'GL' because the VM will only automatically try the '.so' suffix but not '.so.1'.

That is why 'libGL.so.1' is indeed the correct value to be returned from openGLLibraryName on Linux.

For the apicall:'s, if you inspect the byte codes of the method, you will in fact notice that is has already been replaced for you. This happens in OpenGL>>#privateInstallLibrary:, but only updates the method's bytecode, not its source code (which is good, because otherwise this would end up in commits or your changes file).

Yep. As Levente mentioned, you need to switch your browser to show decompiled code to see the actual methods being executed.

You will also see that apicall has been replaced by cdecl which is the right calling convention on Linux.

- Vanessa -

Best,
Tom

Squeak - Dev mailing list

<CDECL kerfuffled on OpenGL. was (Re: OGLUnixX11LE >> glPixelStorei: with:)

Thanks all.

TL;DR "none" of the OpenGL KeyWord API methods are being cdecled, they are all <apicall in the bytecodes and decompile.

preludes:

1. I am able to compile and run a Hello Triangle from http://antongerdelan.net/opengl/hellotriangle.html so basic library stuff is there on Linux64

2. Squeak is :

/home/wm/usr/src/smalltalk/squeak6.0alpha/shared/Squeak6.0alpha-19537-64bit.image
Squeak6.0alpha
latest update: #19634
Current Change Set: OpenGL
Image format 68021 (64 bit)

Examining the source under the "decompile" option:

glPixelStorei: pname with: param
<apicall: void 'glPixelStorei' (ulong long) module: 'libGL.so.1'>
^ self externalCallFailed

which shows that the source code string in my original question, is being replaced.

Here is that "source" view again:

glPixelStorei: pname with: param
"This method was automatically generated."
"void glPixelStorei(GLenum pname, GLint param);"
<apicall: void 'glPixelStorei' (ulong long) module: '#openGLLibraryName'>
^self externalCallFailed

You will notice that the <apicall: has not been replaced with the <cdecl:

That failure is true on both decompile and byteCodes:

<apicall: void 'glPixelStorei' (ulong long) module: 'libGL.so.1'>
41 <F8 78 00> callPrimitive: 120
44 <4C> self
45 <81> send: externalCallFailed
46 <5C> returnTop

it is true for all the methods of a quick scan in Keyword API category.

verifying that the cdecl is wrong, I look in FFITestLibrary ffiPrintString:

and there is a correct looking cdecl.

<cdecl: char* 'ffiPrintString' (char*)>
41 <F8 78 00> callPrimitive: 120
44 <4C> self
45 <81> send: externalCallFailed
46 <5C> returnTop

I check it:

FFITestLibrary new ffiPrintString: 'foo' -> 'foo'

Something more basic is missing from the soup.

I look forward to your insights.

---- On Sun, 10 May 2020 02:17:17 -0400 Beckmann, Tom <[hidden email]> wrote ----

Hi Vanessa,

thank you for clarifying! Do you know if there's any reason to keep the conditional asking for the osVersion to either return 'GL' or 'libgl.so.1'? In its current state it is broken on most linux systems I tested on (mainly Ubuntu-based), but I was wondering whether the correct fix would be to adapt it to the correct matching string 'linux-gnu' or just have it return 'libgl.so.1' always.

Best,
Tom
________________________________________
From: Squeak-dev <[hidden email]> on behalf of Vanessa Freudenberg <[hidden email]>
Sent: Sunday, May 10, 2020 3:19:00 AM
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] OGLUnixX11LE >> glPixelStorei: with:

On Sat, May 9, 2020 at 12:05 AM Beckmann, Tom <[hidden email]<mailto:[hidden email]>> wrote:
Hi there!

Replacing the whole #openGLLibraryName method with a simple
^ 'GL'
should work, as long as you adapt your LD_LIBRARY_PATH to include the arch specific libraries. For example adding
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/"
in your squeak.sh before the vm gets started should make sure that the image finds libgl*. Of course, if your libgl.so.1 is not found under that path, adjust accordingly.

Alternatively, you can also specify the absolute path to the library, e.g.
^ '/usr/lib/x86_64-linux-gnu/libGL.so'
which may be a safer option to start from if you're having troubles getting it to run.

'libGL.so' typically is installed by the opengl dev package as a symlink to 'libGL.so.1'. The user package installs 'libGL.so.1' and will *not* be found by the VM if you just specify 'GL' because the VM will only automatically try the '.so' suffix but not '.so.1'.

That is why 'libGL.so.1' is indeed the correct value to be returned from openGLLibraryName on Linux.

For the apicall:'s, if you inspect the byte codes of the method, you will in fact notice that is has already been replaced for you. This happens in OpenGL>>#privateInstallLibrary:, but only updates the method's bytecode, not its source code (which is good, because otherwise this would end up in commits or your changes file).

Yep. As Levente mentioned, you need to switch your browser to show decompiled code to see the actual methods being executed.

You will also see that apicall has been replaced by cdecl which is the right calling convention on Linux.

- Vanessa -

Best,
Tom

codefrau

Re: <CDECL kerfuffled on OpenGL. was (Re: OGLUnixX11LE >> glPixelStorei: with:)

My best guess is that since apicall is windows-only, it is ignored by the FFI on Linux so the library install code doesn’t even bother to patch it. All other platforms use cdecl, windows uses both (the details really don’t matter for just using FFI, but if you’re interested, look up Pascal-style vs C-style calling conventions, in particular regarding argument popping in caller vs callee).

Besides, you were saying it did work, right?

- Vanessa -

On Sun 10. May 2020 at 09:08, gettimothy via Squeak-dev <[hidden email]> wrote:

Thanks all.

TL;DR "none" of the OpenGL KeyWord API methods are being cdecled, they are all <apicall in the bytecodes and decompile.

preludes:

1. I am able to compile and run a Hello Triangle from http://antongerdelan.net/opengl/hellotriangle.html so basic library stuff is there on Linux64

2. Squeak is :
/home/wm/usr/src/smalltalk/squeak6.0alpha/shared/Squeak6.0alpha-19537-64bit.image
Squeak6.0alpha
latest update: #19634
Current Change Set: OpenGL
Image format 68021 (64 bit)

Examining the source under the "decompile" option:

glPixelStorei: pname with: param
<apicall: void 'glPixelStorei' (ulong long) module: 'libGL.so.1'>
^ self externalCallFailed

which shows that the source code string in my original question, is being replaced.

Here is that "source" view again:

glPixelStorei: pname with: param
"This method was automatically generated."
"void glPixelStorei(GLenum pname, GLint param);"
<apicall: void 'glPixelStorei' (ulong long) module: '#openGLLibraryName'>
^self externalCallFailed

You will notice that the <apicall: has not been replaced with the <cdecl:

That failure is true on both decompile and byteCodes:

<apicall: void 'glPixelStorei' (ulong long) module: 'libGL.so.1'>
41 <F8 78 00> callPrimitive: 120
44 <4C> self
45 <81> send: externalCallFailed
46 <5C> returnTop

it is true for all the methods of a quick scan in Keyword API category.

verifying that the cdecl is wrong, I look in FFITestLibrary ffiPrintString:

and there is a correct looking cdecl.

<cdecl: char* 'ffiPrintString' (char*)>
41 <F8 78 00> callPrimitive: 120
44 <4C> self
45 <81> send: externalCallFailed
46 <5C> returnTop

I check it:

FFITestLibrary new ffiPrintString: 'foo' -> 'foo'

Something more basic is missing from the soup.

I look forward to your insights.

---- On Sun, 10 May 2020 02:17:17 -0400 Beckmann, Tom <[hidden email]> wrote ----

Hi Vanessa,

thank you for clarifying! Do you know if there's any reason to keep the conditional asking for the osVersion to either return 'GL' or 'libgl.so.1'? In its current state it is broken on most linux systems I tested on (mainly Ubuntu-based), but I was wondering whether the correct fix would be to adapt it to the correct matching string 'linux-gnu' or just have it return 'libgl.so.1' always.

Best,
Tom
________________________________________
From: Squeak-dev <[hidden email]> on behalf of Vanessa Freudenberg <[hidden email]>
Sent: Sunday, May 10, 2020 3:19:00 AM
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] OGLUnixX11LE >> glPixelStorei: with:

On Sat, May 9, 2020 at 12:05 AM Beckmann, Tom <[hidden email]<mailto:[hidden email]>> wrote:
Hi there!

Replacing the whole #openGLLibraryName method with a simple
^ 'GL'
should work, as long as you adapt your LD_LIBRARY_PATH to include the arch specific libraries. For example adding
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/"
in your squeak.sh before the vm gets started should make sure that the image finds libgl*. Of course, if your libgl.so.1 is not found under that path, adjust accordingly.

Alternatively, you can also specify the absolute path to the library, e.g.
^ '/usr/lib/x86_64-linux-gnu/libGL.so'
which may be a safer option to start from if you're having troubles getting it to run.

'libGL.so' typically is installed by the opengl dev package as a symlink to 'libGL.so.1'. The user package installs 'libGL.so.1' and will *not* be found by the VM if you just specify 'GL' because the VM will only automatically try the '.so' suffix but not '.so.1'.

That is why 'libGL.so.1' is indeed the correct value to be returned from openGLLibraryName on Linux.

For the apicall:'s, if you inspect the byte codes of the method, you will in fact notice that is has already been replaced for you. This happens in OpenGL>>#privateInstallLibrary:, but only updates the method's bytecode, not its source code (which is good, because otherwise this would end up in commits or your changes file).

Yep. As Levente mentioned, you need to switch your browser to show decompiled code to see the actual methods being executed.

You will also see that apicall has been replaced by cdecl which is the right calling convention on Linux.

- Vanessa -

Best,
Tom

codefrau

Re: OGLUnixX11LE >> glPixelStorei: with:

In reply to this post by Beckmann, Tom

Hi Tom,

the OGLUnix class is used for all Unixen, and 'GL' is a good default for that. We simply special-case Linux.

This could be highlighted by rewriting it as

openGLLibraryName

Smalltalk osVersion = 'linux' ifTrue: [^'libGL.so.1'].

^'GL'

If someone knows the specific conventions on the BSDs or Solaris or whatever, we can add special-cases for them, too, if needed.

- Vanessa -

On Sat, May 9, 2020 at 11:17 PM Beckmann, Tom <[hidden email]> wrote:

Hi Vanessa,

thank you for clarifying! Do you know if there's any reason to keep the conditional asking for the osVersion to either return 'GL' or 'libgl.so.1'? In its current state it is broken on most linux systems I tested on (mainly Ubuntu-based), but I was wondering whether the correct fix would be to adapt it to the correct matching string 'linux-gnu' or just have it return 'libgl.so.1' always.

Best,
Tom
________________________________________
From: Squeak-dev <[hidden email]> on behalf of Vanessa Freudenberg <[hidden email]>
Sent: Sunday, May 10, 2020 3:19:00 AM
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] OGLUnixX11LE >> glPixelStorei: with:

On Sat, May 9, 2020 at 12:05 AM Beckmann, Tom <[hidden email]<mailto:[hidden email]>> wrote:
Hi there!

Replacing the whole #openGLLibraryName method with a simple
^ 'GL'
should work, as long as you adapt your LD_LIBRARY_PATH to include the arch specific libraries. For example adding
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/"
in your squeak.sh before the vm gets started should make sure that the image finds libgl*. Of course, if your libgl.so.1 is not found under that path, adjust accordingly.

Alternatively, you can also specify the absolute path to the library, e.g.
^ '/usr/lib/x86_64-linux-gnu/libGL.so'
which may be a safer option to start from if you're having troubles getting it to run.

'libGL.so' typically is installed by the opengl dev package as a symlink to 'libGL.so.1'. The user package installs 'libGL.so.1' and will *not* be found by the VM if you just specify 'GL' because the VM will only automatically try the '.so' suffix but not '.so.1'.

That is why 'libGL.so.1' is indeed the correct value to be returned from openGLLibraryName on Linux.

For the apicall:'s, if you inspect the byte codes of the method, you will in fact notice that is has already been replaced for you. This happens in OpenGL>>#privateInstallLibrary:, but only updates the method's bytecode, not its source code (which is good, because otherwise this would end up in commits or your changes file).

Yep. As Levente mentioned, you need to switch your browser to show decompiled code to see the actual methods being executed.

You will also see that apicall has been replaced by cdecl which is the right calling convention on Linux.

- Vanessa -

Best,
Tom

codefrau

Re: OGLUnixX11LE >> glPixelStorei: with:

Oh, and regarding 'linux' vs 'linux-gnu': I don't know which VM started that. I'm pretty certain the interpreter VM used 'linux' because that did indeed work when I wrote the original B3DAcceleratorPlugin for X11. That is the plugin that creates the OpenGL context for the Squeak window, whereas the actual OpenGL calls are handled via FFI.

Maybe make the test read (Smalltalk osVersion beginsWith: 'linux'). And maybe also file a bug report with the VM authorities to drop the "-gnu".

- Vanessa -

On Sun, May 10, 2020 at 4:50 PM Vanessa Freudenberg <[hidden email]> wrote:

Hi Tom,

the OGLUnix class is used for all Unixen, and 'GL' is a good default for that. We simply special-case Linux.

This could be highlighted by rewriting it as

openGLLibraryName
Smalltalk osVersion = 'linux' ifTrue: [^'libGL.so.1'].
^'GL'

If someone knows the specific conventions on the BSDs or Solaris or whatever, we can add special-cases for them, too, if needed.

- Vanessa -

On Sat, May 9, 2020 at 11:17 PM Beckmann, Tom <[hidden email]> wrote:
Hi Vanessa,

thank you for clarifying! Do you know if there's any reason to keep the conditional asking for the osVersion to either return 'GL' or 'libgl.so.1'? In its current state it is broken on most linux systems I tested on (mainly Ubuntu-based), but I was wondering whether the correct fix would be to adapt it to the correct matching string 'linux-gnu' or just have it return 'libgl.so.1' always.

Best,
Tom
________________________________________
From: Squeak-dev <[hidden email]> on behalf of Vanessa Freudenberg <[hidden email]>
Sent: Sunday, May 10, 2020 3:19:00 AM
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] OGLUnixX11LE >> glPixelStorei: with:

On Sat, May 9, 2020 at 12:05 AM Beckmann, Tom <[hidden email]<mailto:[hidden email]>> wrote:
Hi there!

Replacing the whole #openGLLibraryName method with a simple
^ 'GL'
should work, as long as you adapt your LD_LIBRARY_PATH to include the arch specific libraries. For example adding
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/"
in your squeak.sh before the vm gets started should make sure that the image finds libgl*. Of course, if your libgl.so.1 is not found under that path, adjust accordingly.

Alternatively, you can also specify the absolute path to the library, e.g.
^ '/usr/lib/x86_64-linux-gnu/libGL.so'
which may be a safer option to start from if you're having troubles getting it to run.

'libGL.so' typically is installed by the opengl dev package as a symlink to 'libGL.so.1'. The user package installs 'libGL.so.1' and will *not* be found by the VM if you just specify 'GL' because the VM will only automatically try the '.so' suffix but not '.so.1'.

That is why 'libGL.so.1' is indeed the correct value to be returned from openGLLibraryName on Linux.

For the apicall:'s, if you inspect the byte codes of the method, you will in fact notice that is has already been replaced for you. This happens in OpenGL>>#privateInstallLibrary:, but only updates the method's bytecode, not its source code (which is good, because otherwise this would end up in commits or your changes file).

Yep. As Levente mentioned, you need to switch your browser to show decompiled code to see the actual methods being executed.

You will also see that apicall has been replaced by cdecl which is the right calling convention on Linux.

- Vanessa -

Best,
Tom

Nicolas Cellier

Re: OGLUnixX11LE >> glPixelStorei: with:

Le lun. 11 mai 2020 à 02:04, Vanessa Freudenberg <[hidden email]> a écrit :

Oh, and regarding 'linux' vs 'linux-gnu': I don't know which VM started that. I'm pretty certain the interpreter VM used 'linux' because that did indeed work when I wrote the original B3DAcceleratorPlugin for X11. That is the plugin that creates the OpenGL context for the Squeak window, whereas the actual OpenGL calls are handled via FFI.

Maybe make the test read (Smalltalk osVersion beginsWith: 'linux'). And maybe also file a bug report with the VM authorities to drop the "-gnu".

non-gnu would be a double negation, which is bad ;)

- Vanessa -

On Sun, May 10, 2020 at 4:50 PM Vanessa Freudenberg <[hidden email]> wrote:
Hi Tom,

the OGLUnix class is used for all Unixen, and 'GL' is a good default for that. We simply special-case Linux.

This could be highlighted by rewriting it as

openGLLibraryName
Smalltalk osVersion = 'linux' ifTrue: [^'libGL.so.1'].
^'GL'

If someone knows the specific conventions on the BSDs or Solaris or whatever, we can add special-cases for them, too, if needed.

- Vanessa -

On Sat, May 9, 2020 at 11:17 PM Beckmann, Tom <[hidden email]> wrote:
Hi Vanessa,

thank you for clarifying! Do you know if there's any reason to keep the conditional asking for the osVersion to either return 'GL' or 'libgl.so.1'? In its current state it is broken on most linux systems I tested on (mainly Ubuntu-based), but I was wondering whether the correct fix would be to adapt it to the correct matching string 'linux-gnu' or just have it return 'libgl.so.1' always.

Best,
Tom
________________________________________
From: Squeak-dev <[hidden email]> on behalf of Vanessa Freudenberg <[hidden email]>
Sent: Sunday, May 10, 2020 3:19:00 AM
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] OGLUnixX11LE >> glPixelStorei: with:

On Sat, May 9, 2020 at 12:05 AM Beckmann, Tom <[hidden email]<mailto:[hidden email]>> wrote:
Hi there!

Replacing the whole #openGLLibraryName method with a simple
^ 'GL'
should work, as long as you adapt your LD_LIBRARY_PATH to include the arch specific libraries. For example adding
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/"
in your squeak.sh before the vm gets started should make sure that the image finds libgl*. Of course, if your libgl.so.1 is not found under that path, adjust accordingly.

Alternatively, you can also specify the absolute path to the library, e.g.
^ '/usr/lib/x86_64-linux-gnu/libGL.so'
which may be a safer option to start from if you're having troubles getting it to run.

'libGL.so' typically is installed by the opengl dev package as a symlink to 'libGL.so.1'. The user package installs 'libGL.so.1' and will *not* be found by the VM if you just specify 'GL' because the VM will only automatically try the '.so' suffix but not '.so.1'.

That is why 'libGL.so.1' is indeed the correct value to be returned from openGLLibraryName on Linux.

For the apicall:'s, if you inspect the byte codes of the method, you will in fact notice that is has already been replaced for you. This happens in OpenGL>>#privateInstallLibrary:, but only updates the method's bytecode, not its source code (which is good, because otherwise this would end up in commits or your changes file).

Yep. As Levente mentioned, you need to switch your browser to show decompiled code to see the actual methods being executed.

You will also see that apicall has been replaced by cdecl which is the right calling convention on Linux.

- Vanessa -

Best,
Tom