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_______________________________________________ Beginners mailing list [email protected] http://lists.squeakfoundation.org/mailman/listinfo/beginners
