VMD-L Mailing List

From: Joshua A. Anderson (joaander_at_umich.edu)
Date: Thu Jan 27 2011 - 06:35:56 CST

On Jan 26, 2011, at 3:31 PM, John Stone wrote:

> This is almost certainly a MacOS X OpenGL driver bug of some kind.

OK, I just double checked on my laptop - it has the same issue and with a very different GPU.

It must be a doozy of a bug: I didn't check all of the missing extensions, but just on that shader object extension, every single pointer comes back NULL: I dropped this at line 416 and got 0x0 for all 17 pointers.
      printf("%p\n", p_glCreateShaderObjectARB);
      printf("%p\n", p_glCreateProgramObjectARB);
....
      printf("%p\n", p_glUniform4fvARB);

I'll see if I can find time next week to setup a minimal repro case to narrow down the issue or for a bug report.

> By the way, I'm curious how stable FLTK 1.3.x and Tcl/Tk 8.6.x are
> on your 64-bit Mac? I'm tempted to put together a 64-bit VMD for MacOS X
> now that they have release candidates for FLTK 1.3.x, but Tcl/Tk 8.6.x is
> still considered a beta. Any comments?

Carolyn and I have been running a build with an old trunk/ build of FLTK 1.3.x for quite a while now and haven't noticed any stability issues. We are still on tcl 8.5.8/.9 as this is the version that macports installs, so I cannot comment on 8.6.x. The build on my iMac is new and made with FLTK 1.3.x RC1 - will let you know if I run into stability issues there.

There is only one apparent problem in that many of the plugins fail to load - leaving the following messages at launch.

The irspecgui package could not be loaded:
The multiseq package could not be loaded:
The pmepot_gui package could not be loaded:
The solvate package could not be loaded:
The autopsf package could not be loaded:
The cggui package could not be loaded:
The dowser_gui package could not be loaded:
The membrane package could not be loaded:
The mutator package could not be loaded:
The autoimd package could not be loaded:

We don't use any of those, so it hasn't bothered us :)

Besides hacking the vmd configure scripts quite a bit to get it to link against the macports built libraries, I did have to hack the VMD source in a few places to get it to run. I've attached these as patch files so you can see exactly what I had to do - I don't know enough about VMD multi-arch builds to know how to implement these changes in a way that won't effect the other builds.

The first hack is a change to use FL::wait(0) instead of flush(), which I believe we discussed on the mailing list a while back - that change had to be made to get my builds to run even before going to x86_64. Without it, I just got the spinning wheel after launching vmd and the windows would not respond to any mouse events.

The second hack is a change I had to make to macosxvmdstart.C to get things to run. Its been a while since I made the change - so I don't exactly remember why I had to. All I know is that it is on the snow-leopard branch in my vmd git repository, so it must not have been needed for the 32-bit builds. I think the change was needed to avoid a compile error. I'm not even sure what the code I changed does!