Re: Differences in OpenGL support on Linux vs. OS X?

(moving to beginners list)

On 07.06.2012, at 22:18, Phil (list) wrote:

It does make sense. The way the OpenGL bindings work isn't entirely obvious, that's true.

What's happening is that in the moment you create an OpenGL object, the FFI methods are rewritten. The module you see in the source code is not the one that gets used. You can verify this by switching to see decompiled code.

The "openGLLibraryName" method tells the system which library to use (e.g. opengl32.dll on Windows, OpenGL.framework on OS X). On Unix, the default is "GL", which the VM expands to "libGL.so".

Now, while this works for Unix in general, it does not work for Linux, unless you install development libraries. E.g. on my Ubuntu system, where I did install "mesa-libGL-devel", I do have that symlink:

$ ll /usr/lib/i386-linux-gnu/mesa/
-rw-r--r--  1 root root     29 May 15 03:14 ld.so.conf
lrwxrwxrwx  1 root root     10 May 15 03:14 libGL.so -> libGL.so.1
lrwxrwxrwx  1 root root     12 May 15 03:14 libGL.so.1 -> libGL.so.1.2
-rw-r--r--  1 root root 358232 May 15 03:15 libGL.so.1.2

However, if you only install "mesa-libGL" and not the "-devel" package, you only have this:

$ ll /usr/lib/i386-linux-gnu/mesa/
-rw-r--r--  1 root root     29 May 15 03:14 ld.so.conf
lrwxrwxrwx  1 root root     12 May 15 03:14 libGL.so.1 -> libGL.so.1.2
-rw-r--r--  1 root root 358232 May 15 03:15 libGL.so.1.2

Therefore, to make it work on a user's Linux install, you have to make openGLLibraryName return "libGL.so.1".

Actually, I'm going to commit this right away ;)

Btw, B3DAcceleratorPlugin is just used for setting up an OpenGL context to render into. Since this is platform-dependent (in contrast to OpenGL itself) and needs VM integration, this part is a plugin and not done via FFI.

- Bert -


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Bert,

On Jun 8, 2012, at 8:51 AM, Bert Freudenberg wrote:

> It does make sense. The way the OpenGL bindings work isn't entirely obvious, that's true.
>

OK, so it's not just me :-)

That's where I went off the reservation.  I remembered reading that module names were ignored on OS X (a long time ago, at least re: OpenGL).  So when I started seeing the module not found messages just assumed 'OK, so Linux works differently' and proceeded to make the changes that initially appeared to fix it rather than recognizing that the issue was that the library.

Having said that and made the change to openGLLibraryName, now I'm getting a segfault on my first OpenGL call.  I'm running Ubuntu 12.04 64-bit desktop with 32-bit compat libs installed and running with proprietary X11/OpenGL (fglrx) drivers and libgl1-mesa-dev installed... do I need to symlink the library to a specific location or is there anything related to my configuration that sounds like the culprit?

Also, it finally dawned on me that I had too many variables in play troubleshooting this while trying to do everything at once (i.e. using a different vm/image/code) so I've installed Squeak 4.3 with the 'classic' VM (though I'm open to using any combination of VM and image that helps sort this out), using the current repo versions of FFI and OpenGL to try to keep the troubleshooting as straightforward as possible.

> Actually, I'm going to commit this right away ;)

Thanks, I'll make sure I grab the latest version of OpenGL when I bring my stuff up to date.  

>
> Btw, B3DAcceleratorPlugin is just used for setting up an OpenGL context to render into. Since this is platform-dependent (in contrast to OpenGL itself) and needs VM integration, this part is a plugin and not done via FFI.
>

I finally got a little bit of clarity on this after catching up on the squeak-dev OpenGL discussions that have happened since I originally did got this working.  I think what was throwing me off was the fact that the B3D provided this nice mirage of appearing to work (at least on my Linux config) while actually taking me further down the wrong path which led up to my initial post.

Thanks,
Phil_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Jun 8, 2012, at 4:56 PM, Phil (list) wrote:

> Having said that and made the change to openGLLibraryName, now I'm getting a segfault on my first OpenGL call.  I'm running Ubuntu 12.04 64-bit desktop with 32-bit compat libs installed and running with proprietary X11/OpenGL (fglrx) drivers and libgl1-mesa-dev installed... do I need to symlink the library to a specific location or is there anything related to my configuration that sounds like the culprit?
>
> Also, it finally dawned on me that I had too many variables in play troubleshooting this while trying to do everything at once (i.e. using a different vm/image/code) so I've installed Squeak 4.3 with the 'classic' VM (though I'm open to using any combination of VM and image that helps sort this out), using the current repo versions of FFI and OpenGL to try to keep the troubleshooting as straightforward as possible.

It turns out there are two flavors (builds) of the same VM and I picked the wrong one:

VM obtained via Ubuntu Software Center download:

squeakvm -version reports:
4.4.7-2357 #1 XShm Tue Apr 24 17:12:58 UTC 2012 gcc 4.6.3
Linux yellow 2.6.24-29-server #1 SMP Tue Oct 11 15:57:27 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
plugin path: /usr/lib/squeak/4.4.7-2357/ [default: /usr/lib/squeak/4.4.7-2357/]

Seg fault

===============================

VM obtained via Squeak all-in-one:

squeakvm -version  reports:
4.4.7-2357 #1 XShm Sun Jan 23 18:17:31 PST 2011 gcc 4.3.2
Linux vps2.piumarta.com 2.6.18-028stab053.10-ent #1 SMP Thu Feb 28 20:34:08 MSK 2008 i686 GNU/Linux
plugin path: /home/phil/Development/Smalltalk/phil-images/sq43/Squeak-4.3-All-in-One.app/Contents/Linux-i686/lib/squeak/4.4.7-2357/ [default: /home/phil/Development/Smalltalk/phil-images/sq43/Squeak-4.3-All-in-One.app/Contents/Linux-i686/lib/squeak/4.4.7-2357/]

Works

Looks like the first one is a 64-bit build and the second 32-bit which would probably explain it.

Thanks,
Phil_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Jun 8, 2012, at 10:03 PM, Phil (list) wrote:

OK, now that I had a working VM/image combo, I was able to make some further progress...

One additional change I discovered I needed to make beyond OpenGL-Core-bf.17.mcz was:

OGLUnix glExtGetProcAddress: aString
        "Answer the function address for the given extension function."
        <cdecl: ulong 'glXGetProcAddressARB' (char*) module: 'libGL.so.1'>
        ^self externalCallFailed

The module: param should still be GL for Unix systems but the #openGLLibraryName parameter did not work (I assume that this call is not being rewritten as the others are)

Now on to Cog VM...

osVersion is returning a different value under Cog so I had to modify:

OGLUnix openGLLibraryName

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

Also, unlike the Squeak VM, Cog wasn't finding the OpenGL library so I had to:

ln -s /usr/lib/libGL.so.1 <plugin-dir>/libGL.so.1

So now I have OpenGL working on both the classic Squeak VM and Cog, but I'm now back to my original problem re: Linux vs. other platforms w.r.t. OpenGL.  Fortunately, it appears someone has previously discovered and resolved the issue via a VM change:

http://lists.squeakfoundation.org/pipermail/vm-dev/2012-June/010797.html

Hopefully this helps anyone else who might run into this on Linux.

Thanks,
Phil_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners