From: John Stone (
Date: Thu Mar 10 2011 - 16:38:33 CST

  A couple of questions for you. Which Tcl/Tk and FLTK versions did you
compile your VMD against? Are they X11-based builds, or native Cocoa
versions? I've successfully updated the VMD code to build for 64-bit
Cocoa, but FLTK and Tk are fighting with each other and crashing during
startup. If I disable Tk, then FLTK works fine and the main GUIs are
loaded and everything else works fine, but then nothing is the
Extensions menu of course. Was your build done using X11 based FLTK/Tk??
My carbon builds used Tcl/Tk 8.5.9 with the "decarbon" patches, and
a current FLTK 1.3.x snapshot, all compiled for Cocoa.
Any comments you have about what you did that worked for you would
be useful.

  John Stone

On Fri, Jan 28, 2011 at 12:16:07PM -0500, Joshua A. Anderson wrote:
> Sure, here is the configure script attached.
> I couldn't figure out how the optional settings were supposed to be used, so I had to hack the hard-coded paths in a few places to link to the libs that macports installs in /opt/local. I think all I had to do for fltk-1.3 was to put it into vmd/lib/fltk and it was able to find it. In the MACOSX86/_64 section you can see some commented out hacks that were originally used when I was using FLTK from macports for 32-bit builds.

> --------
> Joshua A. Anderson, Ph.D.
> Chemical Engineering Department, University of Michigan
> On Jan 27, 2011, at 2:44 PM, John Stone wrote:
> > Joshua,
> > I may have found what's going on with your build, but I will have to
> > try doing a similar build here before I can be sure. There are various
> > MacOS X APIs that Apple has been in the process of deprecating for a while
> > now, and it is possible that actual source of your problem lies with
> > some deprecated MacOS X APIs used in vmdGetProcAddress() that probably have
> > to be replaced for 64-bit builds. At the very least, I'm going to have
> > to revise that code somewhat. Can you send me your version of the 'configure'
> > script so I can compare what you did vs. the current code I have in the tree?
> > If not, no biggie, I can do it all from scratch if necessary once I get the
> > FLTK 1.3.x test build working on a compile/test box here.
> >
> > Cheers,
> > John
> >
> > On Thu, Jan 27, 2011 at 07:35:56AM -0500, Joshua A. Anderson wrote:
> >> 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!
> >>
> >
> >
> >
> >
> > --
> > NIH Resource for Macromolecular Modeling and Bioinformatics
> > Beckman Institute for Advanced Science and Technology
> > University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> > Email: Phone: 217-244-3349
> > WWW: Fax: 217-244-6078
> >
> >

NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email:                 Phone: 217-244-3349
  WWW:      Fax: 217-244-6078