From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue Mar 04 2014 - 10:55:15 CST

Carolyn,
  Can you clear out the DYLD_LIBRARY_PATH variables so they do not
list your CUDA 5.5 directories? Those are the likely cause of your
mismatched .dylib issue which is crashing VMD on startup. VMD includes
the appropriate CUDA libcudart.dylib and and libtlshook.dylib as part
of it's app bundle, so as long as nothing inteferes with the normal
shared library search path, it should run okay.

For VMD binaries you compile yourself, you will need to ensure that
they are either linked with -Wl,rpath or similar flags that tell the
linker where to find its shared library dependencies at runtime, or you
can do what we do and package up the .dylib into the app bundle and
use the install_name_tool and otool to set their dependencies paths
after the fact.

Under normal circumstances, the DYLD_LIBRARY_PATH should not need
to be set globally, and in fact having it set can create problems
for apps that use different shared library versions. This is the same
kind of thing that can happen on Microsoft Windows when multiple apps
are installed using different shared library versions, but one of them
goes and modifies the global shared library search path for its own
benefit.

If an app really need to modify DYLD_LIBRARY_PATH, it's best to do
that within its own startup script.

Cheers,
  John

On Tue, Mar 04, 2014 at 04:47:34PM +0000, Phillips, Carolyn L. wrote:
> FYI
> otool -L libcudart.dylib
> libcudart.dylib:
> @rpath/libcudart.5.5.dylib (compatibility version 0.0.0, current version
> 5.5.28)
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
> (compatibility version 150.0.0, current version 635.21.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 159.1.0)
> On Mar 4, 2014, at 9:35 AM, Phillips, Carolyn L. <cphillips_at_anl.gov>
> wrote:
>
> DYLD_LIBRARY_PATH=/Developer/NVIDIA/CUDA-5.5/lib:/Developer/NVIDIA/CUDA-5.5/lib:
> LD_LIBRARY_PATH is not set.
> On Mar 4, 2014, at 8:51 AM, John Stone <johns_at_ks.uiuc.edu> wrote:
>
> Carolyn,
> Have you checked your environment variables to see if they are
> interfering with VMD's usage of the .dylib that's shipped with it?
> Anything in DYLD_FRAMEWORK_PATH or LD_LIBRARY_PATH that adds CUDA?
>
> Cheers,
> John
>
> On Tue, Mar 04, 2014 at 03:45:23PM +0000, Phillips, Carolyn L. wrote:
>
> So I have now updated my cuda driver to 5.5.47 and then grabbed
> the VMD
> 1.9.1 binary again
> Same problem
> /Applications/VMD\ 1.9.1\ 2.app/Contents/MacOS/startup.command ;
> exit;
> dyld: Library not loaded: @executable_path/libcudart.dylib
> Referenced from: /Applications/VMD 1.9.1
> 2.app/Contents/MacOS/../Resources/VMD.app/Contents/MacOS/VMD
> Reason: Incompatible library version: VMD requires version 1.1.0
> or
> later, but libcudart.dylib provides version 0.0.0
> /Applications/VMD 1.9.1 2.app/Contents/MacOS/startup.command: line
> 7:
> 47884 Trace/BPT trap: 5
> "$p/../Resources/VMD.app/Contents/MacOS/VMD"
> $*
> logout
> From the error message above I wonder if your install_name_tool
> and otool
> is finding the libcudart.dylib at all. (version 0.0.0 ??)
> Also, I noticed that the the /usr/local/cuda directory all points
> to the
> Developer folder as well
> lrwxr-xr-x 1 root wheel 35 Nov 21 09:06 EULA.txt ->
> /Developer/NVIDIA/CUDA-5.5/EULA.txt
> lrwxr-xr-x 1 root wheel 30 Nov 21 09:06 bin ->
> /Developer/NVIDIA/CUDA-5.5/bin
> lrwxr-xr-x 1 root wheel 30 Nov 21 09:06 doc ->
> /Developer/NVIDIA/CUDA-5.5/doc
> lrwxr-xr-x 1 root wheel 33 Nov 21 09:06 extras ->
> /Developer/NVIDIA/CUDA-5.5/extras
> lrwxr-xr-x 1 root wheel 34 Nov 21 09:06 include ->
> /Developer/NVIDIA/CUDA-5.5/include
> drwxr-xr-x 28 root wheel 952 Mar 4 08:34 lib
> lrwxr-xr-x 1 root wheel 36 Nov 21 09:06 libnsight ->
> /Developer/NVIDIA/CUDA-5.5/libnsight
> lrwxr-xr-x 1 root wheel 34 Nov 21 09:06 libnvvp ->
> /Developer/NVIDIA/CUDA-5.5/libnvvp
> lrwxr-xr-x 1 root wheel 31 Nov 21 09:06 nvvm ->
> /Developer/NVIDIA/CUDA-5.5/nvvm
> lrwxr-xr-x 1 root wheel 33 Nov 21 09:06 open64 ->
> /Developer/NVIDIA/CUDA-5.5/open64
> lrwxr-xr-x 1 root wheel 34 Nov 21 09:06 samples ->
> /Developer/NVIDIA/CUDA-5.5/samples
> lrwxr-xr-x 1 root wheel 30 Nov 21 09:06 src ->
> /Developer/NVIDIA/CUDA-5.5/src
> lrwxr-xr-x 1 root wheel 32 Nov 21 09:06 tools ->
> /Developer/NVIDIA/CUDA-5.5/tools
> and in lib
> lrwxr-xr-x 1 root wheel 46 Nov 21 09:06 libcudart.dylib ->
> /Developer/NVIDIA/CUDA-5.5/lib/libcudart.dylib
> On Mar 3, 2014, at 9:08 AM, John Stone <johns_at_ks.uiuc.edu> wrote:
>
> Carolyn,
> Let us know if Maxim's suggestion makes any difference.
> Maxim, Thanks for the tip.
>
> Another thing to check is to see which CUDA runtime .dylib your
> locally
> compiled VMD is actually picking up when it runs.
> Since you have several on your system, one question I would ask
> is
> whether
> anything would have changed your DYLD_FRAMEWORK_PATH or
> LD_LIBRARY_PATH
> or similar environment variables in such a way that VMD is now
> picking
> up the wrong .dylib where it had not previously.
>
> In the binaries we produce, we use the MacOS X
> 'install_name_tool' and
> 'otool' commands to set some of our library dependency paths in
> such a
> way that they are unlikely to be overridden by environment
> variable
> changes like the ones above, but if you compile VMD from source
> and
> don't do this on your own, then anything could potentially
> happen if
> system-wide paths are changed such that the wrong .dylib shows
> up
> earlier
> in the search path.
>
> It should be easy to attach a debugger to your VMD during
> startup to
> help track down what's going on there. When the debugger
> attaches, it
> will
> usually print out what shared libraries the app is linked
> against and
> what
> they were resolved to, and this would help track down if there's
> something
> bad going on with mismatched .dylib files...
>
> Cheers,
> John Stone
>
> On Sun, Mar 02, 2014 at 05:54:44PM -0600, Maxim Belkin wrote:
>
> Hi Carolyn,
>
> The issue you are facing is caused by CUDA drivers. Try
> installing the
> latest CUDA 5.5.43 drivers. Until this version, CUDA didn?t
> work on a
> great deal of GPUs under Mavericks.
>
> Maxim
>
> On Mar 2, 2014, at 4:54 PM, Phillips, Carolyn L.
> <cphillips_at_anl.gov>
> wrote:
>
> A little search turned up these versions.
>
> ./NVIDIA/CUDA-5.5/lib/libcudart.dylib
> ./VMD 1.9.1.app/Contents/vmd/libcudart.dylib
> ./MATLAB_R2013b.app/bin/maci64/libcudart.dylib
> /local/cuda/lib/libcudart.dylib
>
> I think the first it the one it should be finding.
> I don?t know why such a library is included in vmd, but I am
> going
> to assume its legitimate
> Same for the Matlab one
> I assume it may be the /local version that is creating the
> problem.
>
> FYI,
>
> which nvcc
> /Developer/NVIDIA/CUDA-5.5/bin/nvcc
>
> -Carolyn
> On Mar 2, 2014, at 3:20 PM, Axel Kohlmeyer
> <akohlmey_at_gmail.com>
> wrote:
>
> On Sun, Mar 2, 2014 at 3:42 PM, Phillips, Carolyn L.
> <cphillips_at_anl.gov> wrote:
>
> Hello,
>
> I am trying to pin down why my version of VMD 1.91.1
> built from
> source has
> started seg faulting. (Note, i cannot run vmd -debug
> because
> gdb is no
> longer included with Xcode on Mavericks as a command
> line tool,
> you can get
> it from macports but it is now called ggdb )
>
> I started with verifying if I download and run the
> VMD1.9.1
> binary that it
> still works. What I found is that this version does
> work,
> MacOS X OpenGL
> (32-bit Intel x86) (Apple MacOS-X 10.5.x or later).
>
> This version crashes, MacOS X OpenGL, CUDA (32-bit
> Intel x86)
> (Apple
> MacOS-X 10.5.x or later with CUDA)
>
> It cannot seem to interface with the cuda library
> correctly
>
> /Volumes/VMD-1.9.1/VMD\
> 1.9.1.app/Contents/MacOS/startup.command
> ; exit;
> dyld: Library not loaded:
> @executable_path/libcudart.dylib
> Referenced from: /Volumes/VMD-1.9.1/VMD
> 1.9.1.app/Contents/MacOS/../Resources/VMD.app/Contents/MacOS/VMD
> Reason: Incompatible library version: VMD requires
> version 1.1.0
> or later,
> but libcudart.dylib provides version 0.0.0
>
> hi carolyn,
>
> this looks like VMD picks up some old and incompatible
> version of
> the
> cuda runtime library from somewhere.
>
> axel.
>
> /Volumes/VMD-1.9.1/VMD
> 1.9.1.app/Contents/MacOS/startup.command:
> line 7:
> 2533 Trace/BPT trap: 5
> "$p/../Resources/VMD.app/Contents/MacOS/VMD" $*
> logout
>
> [Process completed]
>
> My system is
>
> Mac OSX 10.9.1
> Graphics NVIDIA GeForce GT 750M 2048 MB
> Processor 2.3 GHz Intel Core i7
>
> -Carolyn
>
> --
> Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0
> College of Science & Technology, Temple University,
> Philadelphia
> PA, USA
> International Centre for Theoretical Physics, Trieste.
> Italy.
>
> --
> NIH Center for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> http://www.ks.uiuc.edu/~johns/ Phone: 217-244-3349
> http://www.ks.uiuc.edu/Research/vmd/
>
> --
> NIH Center for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> http://www.ks.uiuc.edu/~johns/ Phone: 217-244-3349
> http://www.ks.uiuc.edu/Research/vmd/

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/