(moving to beginners list)
On 07.06.2012, at 22:18, Phil (list) wrote:
Bert,
On Jun 7, 2012, at 6:25 AM, Bert Freudenberg wrote:
This is probably unrelated, but you are apparently not using the latest OpenGL package, and you messed it up severely. Why is it using "B3DAcceleratorPlugin" instead of "libGL"?! I had to revert openGLLibraryName to make it work at all.
The short answer is that my work with OpenGL predated a lot of the discussion/documentation that's now available for Squeak and involved a lot of trial and error, so yes I'm considerably out of date and probably doing some screwy/wrong things and plan to correct that.
I *think* you identified my issue re: B3DAcceleratorPlugin. When I initially tried to get the code running on Linux I was getting module not found errors and so I incorrectly did a search and replace to replace the module names (and accidentally went a little beyond that) which resulted in the appearance of OpenGL working on Ubuntu 12.04... and it sort of works (i.e. it's drawing but very poorly via B3D and I think I was/am getting confused re: internal vs. external plugins and how B3D fit into the mix with OpenGL. I vaguely recall going down this path several years ago when I was attempting to initially get it running on OS X.)
Based on some further research on squeak-dev, the real issue appears to be my machines configuration (libGL isn't where the VM expects it)... and you're right, that's not a vm-dev issue but I do thank you for helping to point me in what appears to be the right direction to resolve this.
Now if none of what I've said makes sense, then I'm still lost but I'll take further discussion off of vm-dev.
Thanks, Phil
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 -
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 :-)
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".
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
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
On Jun 8, 2012, at 10:03 PM, Phil (list) wrote:
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.
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@lists.squeakfoundation.org
-
Bert Freudenberg -
Phil (list)