|
From: Bruce S. <Bru...@nc...> - 2011-12-08 00:31:53
|
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
|