visualpython-users

[Visualpython-users] Linux workaround

[Bruce S. <Bru...@nc...>]

Now that I was able to work on the Linux crashes, I immediately found
that the crash occurs on the following statement in the realize
routine in src/core/display_kernel.cpp:

// The test is a hack so that subclasses not bothering to implement
getProcAddress just
		//   don't get any extensions.
		if (getProcAddress("display_kernel::getProcAddress") != notImplemented)
			glext.init( *this );

If this statement is commented out, VPython runs on the latest Ubuntu,
but there are no materials. I'll look deeper into this, but if you're
capable of building from source you can have a working VPython just by
compiling without the offending statement. The comment "The test is a
hack" suggests something that might well go bad with a system change,
though this hasn't been a problem on Windows or Mac.

Bruce Sherwood

Re: [Visualpython-users] Linux workaround

[Bruce S. <Bru...@nc...>]

Where I got to today is finding that the real problem is in
src/gtk2/display.cpp:

display::EXTENSION_FUNCTION
display::getProcAddress(const char* name) {
	return (EXTENSION_FUNCTION)Gdk::GL::get_proc_address( name );
}

Calling Gdk::GL::get_proc_address( name ) crashes the program. The
purpose of this routine is to obtain information about extensions to
OpenGL. The "hack" mentioned earlier (see below) isn't the actual
problem; the problem is that the get_proc_address() function which
worked on earlier Ubuntu/Debian systems doesn't work now (and I guess
maybe it doesn't work on Fedora, either).

I have the impression that VPython as is works for Linux users with
low-end graphics cards, probably because there are no relevant
extensions asked for.

At the moment, I can only recommend the workaround described below. It
would seem necessary to find a different way to look up extensions,
one that doesn't use the get_proc_address() function. I welcome
suggestions from those of you who are knowledgeable about OpenGL.

Bruce Sherwood

On Tue, Dec 6, 2011 at 5:28 PM, Bruce Sherwood <Bru...@nc...> wrote:
> Now that I was able to work on the Linux crashes, I immediately found
> that the crash occurs on the following statement in the realize
> routine in src/core/display_kernel.cpp:
>
> // The test is a hack so that subclasses not bothering to implement
> getProcAddress just
>                //   don't get any extensions.
>                if (getProcAddress("display_kernel::getProcAddress") != notImplemented)
>                        glext.init( *this );
>
> If this statement is commented out, VPython runs on the latest Ubuntu,
> but there are no materials. I'll look deeper into this, but if you're
> capable of building from source you can have a working VPython just by
> compiling without the offending statement. The comment "The test is a
> hack" suggests something that might well go bad with a system change,
> though this hasn't been a problem on Windows or Mac.
>
> Bruce Sherwood

Re: [Visualpython-users] Linux workaround

[Kevin K. <ka...@so...>]

I'm not an OpenGL user, but it looks like the OpenGL Extension
 Wrangler at
	 http://glew.sourceforge.net/ 
may be what you need

    The OpenGL Extension Wrangler Library (GLEW) is a cross-platform
    open-source C/C++ extension loading library. GLEW provides
    efficient run-time mechanisms for determining which OpenGL
    extensions are supported on the target platform. OpenGL core and
    extension functionality is exposed in a single header file. GLEW
    has been tested on a variety of operating systems, including
    Windows, Linux, Mac OS X, FreeBSD, Irix, and Solaris.

Re: [Visualpython-users] Linux workaround

[Bruce S. <Bru...@nc...>]

Yes, I too have my eye on that library, but I'm missing something.
It's true that I need to be able to determine whether an extension is
available, but I'm having trouble finding out how to get the address
of the extension, which is what the (failing) get_proc_address is
supposed to do.

Bruce Sherwood

On Wed, Dec 7, 2011 at 5:44 PM, Kevin Karplus <ka...@so...> wrote:
>
> I'm not an OpenGL user, but it looks like the OpenGL Extension
>  Wrangler at
>         http://glew.sourceforge.net/
> may be what you need
>
>    The OpenGL Extension Wrangler Library (GLEW) is a cross-platform
>    open-source C/C++ extension loading library. GLEW provides
>    efficient run-time mechanisms for determining which OpenGL
>    extensions are supported on the target platform. OpenGL core and
>    extension functionality is exposed in a single header file. GLEW
>    has been tested on a variety of operating systems, including
>    Windows, Linux, Mac OS X, FreeBSD, Irix, and Solaris.

Re: [Visualpython-users] Linux workaround

[Kevin K. <ka...@so...>]

Bruce, I'm not sure why you need the address of an extension.

Once you've determined that an extension is available, can't you just
call its functions?

That's what the examples at
	http://www.opengl.org/resources/features/OGLextensions/ 
imply anyway.

What are you trying to accomplish that needs the address of an extension?

Kevin Karplus

Re: [Visualpython-users] Linux workaround

[Kevin K. <ka...@so...>]

I retract my previous question.  It seems that Microsoft implemented
OpenGL in a weird way, so that on Windows systems you need
wglGetProcAddress and other awkward workarounds.

It looks like all the code that need the addresses is Windows-specific
and should be isolated to parts of the code only compiled for Windows systems.

(info from further down on the
http://www.opengl.org/resources/features/OGLextensions/ 
page I mentioned in the retracted message.)

Re: [Visualpython-users] Linux workaround

[Bruce S. <Bru...@nc...>]

Yes, I think you're right. I was going around in circles on the issue
of getting a pointer to the function when, as you say, apparently
that's needed only on Windows. Apparently the VPython code needs to be
refactored slightly to not ask for the pointer if on Linux, since for
some reason that no longer works, needed or not.

Note that the Mac code in Visual is this (and notice the comments):

#include <dlfcn.h>
display::EXTENSION_FUNCTION
display::getProcAddress(const char* name) {
	void *lib = dlopen( (const char *)0L, RTLD_LAZY | RTLD_GLOBAL );
	void *sym = dlsym( lib, name );
	dlclose( lib );
	return (EXTENSION_FUNCTION)sym;
	//return (EXTENSION_FUNCTION)::wglGetProcAddress( name ); // Windows
	//return (EXTENSION_FUNCTION)Gdk::GL::get_proc_address( name ); // GTK2
}

Bruce Sherwood

On Wed, Dec 7, 2011 at 8:23 PM, Kevin Karplus <ka...@so...> wrote:
>
> I retract my previous question.  It seems that Microsoft implemented
> OpenGL in a weird way, so that on Windows systems you need
> wglGetProcAddress and other awkward workarounds.
>
> It looks like all the code that need the addresses is Windows-specific
> and should be isolated to parts of the code only compiled for Windows systems.
>
> (info from further down on the
> http://www.opengl.org/resources/features/OGLextensions/
> page I mentioned in the retracted message.)
>